Bem-vindo ao Curso de Python Backend

Aprenda Python do zero ao profissional com um curso completo, prático e estruturado!

🎯 Sobre o Curso

Este curso foi desenvolvido para te levar do básico ao avançado em Python, com foco em desenvolvimento backend. Você aprenderá através de aulas práticas, exercícios, projetos e quizzes interativos.

O que você vai aprender: - Fundamentos da linguagem Python - Estruturas de dados e controle de fluxo - Programação Orientada a Objetos - Manipulação de arquivos e exceções - APIs e requisições HTTP - Testes e boas práticas

🚀 Comece Agora

Aulas

16 aulas completas organizadas em 6 módulos, do básico ao avançado.

Ver todas as aulas
Slides

Slides interativos com RevealJS para todas as aulas do curso.

Acessar slides
Exercícios

Pratique com exercícios para cada aula e fixe o conteúdo.

Ver exercícios
Quizzes

Teste seus conhecimentos com quizzes interativos.

Fazer quizzes
Projetos

Desenvolva projetos práticos para aplicar o que aprendeu.

Ver projetos
Configuração

Guias de instalação e configuração do ambiente Python.

Configurar ambiente

📚 Estrutura do Curso

O curso está organizado em 6 módulos progressivos:

Módulo 1 – Fundamentos (Aulas 01-04)
Módulo 2 – Estruturas de Controle (Aulas 05-08)
Módulo 3 – Funções e Modularização (Aulas 09-10)
Módulo 4 – Arquivos e Exceções (Aulas 11-12)
Módulo 5 – Programação Orientada a Objetos (Aulas 13-14)
Módulo 6 – Ecossistema (Aulas 15-16)

🎓 Como Usar Este Curso

Configure seu ambiente - Siga os guias de configuração
Comece pela Aula 01 - Vá para Aulas e comece do início
Pratique regularmente - Faça os exercícios e projetos de cada aula
Teste seus conhecimentos - Complete os quizzes para validar seu aprendizado
Revise com os slides - Use os slides para revisão rápida

Pronto para começar? Ir para Aula 01

Sobre o Curso

🎓 Python Backend - Do Zero ao Profissional

Este é um curso completo e estruturado de Python com foco em desenvolvimento backend. Desenvolvido para levar você do básico ao avançado, com uma abordagem prática e hands-on.

🎯 Objetivos do Curso

Dominar Python

Aprender a sintaxe, estruturas de dados e conceitos fundamentais da linguagem Python.
Programação Orientada a Objetos

Entender e aplicar os princípios de POO: classes, objetos, herança e polimorfismo.
Desenvolvimento Backend

Trabalhar com APIs, requisições HTTP e integração com serviços externos.
Boas Práticas

Escrever código limpo, testável e seguindo as melhores práticas da indústria.

📚 O Que Você Vai Aprender

Módulo 1 – Fundamentos

Introdução ao Python e configuração do ambiente
Variáveis, tipos de dados e operadores
Estruturas condicionais e controle de fluxo

Módulo 2 – Estruturas de Controle

Laços de repetição (for, while)
Listas, tuplas e sets
Dicionários e manipulação de coleções

Módulo 3 – Funções e Modularização

Criação e uso de funções
Módulos e pacotes
Organização de código

Módulo 4 – Arquivos e Exceções

Leitura e escrita de arquivos
Tratamento de exceções
Gerenciamento de erros

Módulo 5 – Programação Orientada a Objetos

Classes e objetos
Herança e polimorfismo
Encapsulamento e abstração

Módulo 6 – Ecossistema Python

APIs e requisições HTTP
Testes automatizados
Boas práticas e padrões de código

🛠️ Metodologia

Aulas Teóricas

Conteúdo explicativo com exemplos práticos e slides interativos.
Exercícios Práticos

Listas de exercícios para fixar o conteúdo de cada aula.
Projetos Reais

Desenvolva projetos práticos aplicando os conceitos aprendidos.
Quizzes Interativos

Teste seus conhecimentos com quizzes ao final de cada módulo.

👨‍🎓 Para Quem é Este Curso

Iniciantes que querem aprender programação do zero
Desenvolvedores que querem migrar para Python
Estudantes de ciência da computação e áreas relacionadas
Profissionais que querem se especializar em backend

📋 Pré-requisitos

Computador com Windows, Linux ou macOS
Vontade de aprender e praticar
Não é necessário conhecimento prévio de programação!

🎖️ O Que Você Receberá

✅ 16 aulas completas e estruturadas
✅ Slides interativos para todas as aulas
✅ Exercícios práticos com soluções
✅ Projetos reais para portfólio
✅ Quizzes para autoavaliação
✅ Guias de configuração de ambiente

🚀 Comece Agora

Pronto para começar sua jornada em Python?

Ir para Aula 01 Configurar Ambiente

Dúvidas? Entre em contato ou acesse a documentação completa.

Aulas

Aulas do Curso

Bem-vindo à seção de aulas! Aqui você encontra todo o conteúdo do curso organizado por módulos.

📚 Módulos do Curso

Módulo 1 – Fundamentos
Módulo 2 – Estruturas de Controle
Módulo 3 – Funções e Modularização
- Aula 09 - Funções
- Aula 10 - Módulos e Pacotes
Módulo 4 – Arquivos e Exceções
- Aula 11 - Manipulação de Arquivos
- Aula 12 - Tratamento de Exceções
Módulo 5 – Programação Orientada a Objetos
- Aula 13 - Introdução a Classes e Objetos
- Aula 14 - Herança e Polimorfismo
Módulo 6 – Ecossistema
- Aula 15 - APIs e Requisições HTTP
- Aula 16 - Testes e Boas Práticas

Módulo 1 – Fundamentos

Aula 01 – O que é controle de versão e por que usar Git

🎯 Objetivos de Aprendizagem

Entender o conceito de Controle de Versão e sua importância.
Diferenciar Git (software) de GitHub (plataforma).
Compreender a diferença entre sistemas centralizados e distribuídos.
Conhecer a história e a popularidade do Git no mercado de TI.

📚 Conteúdo

1. O Problema do "Versão Final.doc"

Você já trabalhou em um arquivo importante e acabou criando cópias como: - tcc_final.doc - tcc_final_agora_vai.doc - tcc_final_IMPRIMIR.doc

Isso é controle de versão manual e é propenso a falhas. Você perde o histórico do que mudou, quem mudou e por que mudou.

2. O que é um Sistema de Controle de Versão (VCS)?

Um VCS (Version Control System) é um software que registra as mudanças em um ou mais arquivos ao longo do tempo. Ele permite que você: - Reverta arquivos para um estado anterior. - Compare mudanças ao longo do tempo. - Veja quem modificou o que. - Recupere arquivos perdidos.

3. Git: O Padrão da Indústria

O Git é um Sistema de Controle de Versão Distribuído. - Distribuído significa que cada desenvolvedor tem uma cópia completa de todo o histórico do projeto em seu computador, não apenas a última versão. - Foi criado por Linus Torvalds (criador do Linux) em 2005. - É rápido, eficiente e permite trabalho offline.

4. Git vs GitHub

É crucial não confundir os dois: - Git: É a ferramenta (software) que você instala no seu computador para gerenciar versões. Funciona localmente. - GitHub: É uma plataforma na nuvem que hospeda repositórios Git. Funciona como uma rede social para desenvolvedores e facilita o trabalho em equipe. Analogia: O Git é como o Microsoft Word (ferramenta), e o GitHub é como o Google Drive (onde você guarda e compartilha).

📽 Roteiro de Slides

O Caos dos Arquivos Manuais (v1, v2, final)
O que é Version Control System (VCS)?
Benefícios: Histórico, Backup, Trabalho em Equipe
Git: Distribuído, Rápido, Padrão de Mercado
Git vs GitHub: Ferramenta Local vs Plataforma na Nuvem
Glossário Inicial: Repositório, Commit (visão geral)

📝 Quiz

Qual é a principal função de um Sistema de Controle de Versão?
Quem criou o Git?
Qual a diferença fundamental entre Git e GitHub?
O que significa o Git ser "Distribuído"?
Qual problema o Git resolve?

Gabarito

1: A 2: C 3: B 4: D 5: A

🛠 Exercícios

Verificação Inicial: Abra seu terminal e digite:
```
$ git --version
git version 2.40.0.windows.1
```
Se der erro, não se preocupe, instalaremos na próxima aula.
Criação de Conta: Acesse github.com e crie sua conta gratuita, caso ainda não tenha. Escolha um nome de usuário profissional.
Simulação Manual: Crie uma pasta chamada simulacao_vcs no seu computador. Crie um arquivo texto, faça uma alteração e salve uma cópia v2. Note a dificuldade de gerenciar isso manualmente.

🚀 Projeto da Aula

Neste curso, construiremos um Portfólio Profissional. - Passo 1: Crie uma pasta no seu computador (Desktop ou Documentos) chamada meu-portfolio-git. - Passo 2: Dentro dela, crie um arquivo de texto simples chamado sobre.txt e escreva apenas seu nome. - Passo 3: Guarde essa pasta. Nas próximas aulas, vamos transformá-la em um repositório Git e subi-la para o GitHub.

Aula 02 – Instalando e configurando o Git

🎯 Objetivos de Aprendizagem

Instalar o Git no seu sistema operacional (Windows, Mac ou Linux).
Configurar sua identidade (nome e email) no Git.
Verificar se a instalação e configuração foram bem-sucedidas.
Entender onde essas configurações ficam salvas.

📚 Conteúdo

1. Instalação

Windows

Acesse git-scm.com.
Baixe a versão para Windows.
Execute o instalador.
Importante: Na tela de escolha de editor, pode manter o padrão (Vim) ou mudar para VS Code se já tiver instalado. Nas outras opções, "Next" (Avançar) é seguro para iniciantes.
Após instalar, procure por "Git Bash" no menu Iniciar. Esse será seu terminal principal.

macOS

Se você tem o Homebrew instalado: brew install git.
Ou baixe o instalador em git-scm.com.

Linux (Ubuntu/Debian)

Abra o terminal e rode: sudo apt-get update e depois sudo apt-get install git-all.

2. Configuração Inicial (Obrigatória)

O Git precisa saber quem você é para atribuir a autoria das mudanças.

Abra o terminal (Git Bash no Windows) e execute:

git config --global user.name "Seu Nome Completo"
git config --global user.email "seu.email@exemplo.com"

Dica: Use o mesmo email da sua conta GitHub.

3. Verificando as Configurações

Para ver se deu certo, digite:

git config --list

Você deve ver seu nome e email na lista que aparecerá. Pressione Q para sair da lista se ela for longa.

📽 Roteiro de Slides

Download do Git (site oficial git-scm.com)
Passo a passo da instalação (Windows: Next, Next, Next...)
O Terminal: Git Bash (Windows) vs Terminal (Mac/Linux)
Configuração de Identidade:
git config --global user.name
git config --global user.email
Por que configurar? (Autoria e Segurança)
Verificando tudo: git config --list

📝 Quiz

Qual o site oficial para baixar o Git?
Qual comando define seu nome de usuário no Git?
O que a opção --global faz nas configurações?
Qual terminal é instalado junto com o Git no Windows?
Como verificar as configurações atuais?

Gabarito

1: B 2: A 3: C 4: D 5: B

🛠 Exercícios

Instalação: Baixe e instale o Git no seu computador.
Setup de Identidade: Configure seu nome e email corretamente.
Validação: Use o comando git config --list e tire um print ou anote o resultado para garantir que está correto.

🚀 Projeto da Aula

Voltando à pasta meu-portfolio-git: 1. Clique com o botão direito dentro da pasta. 2. Selecione "Open Git Bash here" (se estiver no Windows). 3. Digite git --version para confirmar que o Git está rodando DENTRO da sua pasta de projeto. 4. Ainda não vamos iniciar o repositório, apenas garantir que o terminal funciona no lugar certo.

Aula 03 – Repositórios, commits e histórico

🎯 Objetivos de Aprendizagem

Iniciar um repositório Git (git init).
Entender as três áreas do Git: Working Directory, Staging Area e Repository.
Realizar o primeiro commit (git commit).
Visualizar o histórico de mudanças (git log).
Verificar o estado dos arquivos (git status).

📚 Conteúdo

1. Inicializando um Repositório

Para transformar uma pasta comum em um projeto rastreado pelo Git:

git init

Isso cria uma pasta oculta .git onde toda a mágica acontece.

2. O Ciclo de Vida dos Arquivos (As 3 Áreas)

Entender isso é fundamental: 1. Working Directory (Área de Trabalho): Onde você edita e cria arquivos. 2. Staging Area (Área de Preparação): Uma área intermediária onde você escolhe o que vai entrar no próximo pacote (commit). 3. Repository (Repositório/.git): Onde as versões confirmadas são salvas permamentemente.

3. Comandos Essenciais

git status: O comando mais importante. Mostra em que estado seus arquivos estão (modificados, preparados ou commitados).
git add <arquivo>: Move o arquivo do Working Directory para a Staging Area.
git commit -m "mensagem": Move o que está na Staging Area para o Repositório, criando uma "foto" definitiva daquela versão.

4. Git Log

Para ver a história do que aconteceu:

git log

Ele mostra o ID do commit (hash), o autor, a data e a mensagem.

📽 Roteiro de Slides

O comando git init: Onde tudo começa.
As 3 Áreas:
Working Directory (Sua mesa bagunçada)
Staging Area (A caixa pronta para envio)
Repository (O arquivo morto organizado)
O fluxo básico: Edit -> Add -> Commit.
Por que mensagens de commit importam?
git status: Seu melhor amigo.
git log: Olhando para o passado.

📝 Quiz

Qual comando transforma uma pasta em um repositório Git?
Para onde o comando git add envia os arquivos?
Qual a função do git commit?
O que o git status faz?
Qual comando mostra o histórico de commits?

Gabarito

1: B 2: C 3: A 4: D 5: B

🛠 Exercícios

Init: Crie uma pasta teste-git, entre nela e rode git init.
Status: Rode git status e veja o que acontece.
Criar e Adicionar: Crie um arquivo oi.txt, rode git add oi.txt.
Commitar: Rode git commit -m "Primeiro commit".
Log: Rode git log para ver seu feito registrado.

🚀 Projeto da Aula

Voltando ao nosso meu-portfolio-git: 1. Abra o terminal na pasta. 2. Digite: git init. (Agora é oficial!) 3. Digite: git status. (Veja o sobre.txt em vermelho/untracked). 4. Digite: git add sobre.txt. 5. Digite: git status. (Veja o arquivo verde/staged). 6. Digite: git commit -m "Adiciona arquivo sobre mim". 7. Digite: git log. (Veja seu nome eternizado no histórico).

Aula 04 – Branches e merges

🎯 Objetivos de Aprendizagem

Entender o conceito de Branches (Ramificações).
Criar e navegar entre branches (git branch, git switch).
Realizar a fusão de alterações (git merge).
Compreender a segurança de trabalhar em branches separados.

📚 Conteúdo

1. O que são Branches?

Imagine que você está criando um jogo. Você tem a versão funcional (chamada main ou master). Você quer testar uma "fase de gelo", mas não quer estragar o jogo principal se der errado. No Git, você cria uma Branch (ramo/galho). É uma cópia paralela do seu projeto onde você pode experimentar livremente.

2. Comandos Principais

git branch: Lista todos os branches.
git branch <nome>: Cria um novo branch.
git switch <nome>: Muda para o branch especificado. (Antigamente usava-se checkout).
git merge <nome>: Traz as mudanças de OUTRO branch para o branch ATUAL.

3. O Fluxo de Trabalho Seguro

Nunca trabalhe direto na main! 1. Crie uma branch para sua tarefa: git branch nova-funcionalidade. 2. Mude para ela: git switch nova-funcionalidade. 3. Trabalhe, adicione e commite à vontade. 4. Volte para a main e "puxe" as novidades com git merge.

📽 Roteiro de Slides

O conceito de "Multiverso" ou "Linhas do Tempo Paralelas".
Branch Principal (main/master) vs Branches de Recurso (feature).
Por que usar branches? (Isolamento de risco).
Criando (git branch) e Trocando (git switch).
Unindo tudo (git merge).
O que acontece com os arquivos quando troco de branch? (Demonstração visual).

📝 Quiz

Qual é o nome padrão mais comum para o branch principal hoje em dia?
Para que serve criar um branch?
Qual comando cria um novo branch sem mudar para ele?
Qual comando usamos para trocar de branch?
O que o git merge faz?

Gabarito

1: C 2: B 3: A 4: D 5: B

🛠 Exercícios

Criar Branch: No seu projeto de teste teste-git, crie uma branch chamada experiencia.
Mudar: Mude para essa branch com git switch experiencia.
Alterar: Crie um arquivo teste.txt e faça o commit.
Voltar: Volte para a main (git switch main).
Observar: Veja que o arquivo teste.txt sumiu! (Ele está seguro na outra "linha do tempo").
Merge: Estando na main, digite git merge experiencia para trazer o arquivo de volta.

🚀 Projeto da Aula

No seu meu-portfolio-git: 1. Crie uma branch chamada adiciona-contato. 2. Mude para ela: git switch adiciona-contato. 3. Crie um arquivo contato.txt com seu email. 4. git add contato.txt. 5. git commit -m "Cria arquivo de contato". 6. Volte para a branch principal (main ou master). Note que o contato.txt sumiu da pasta. 7. Faça o merge: git merge adiciona-contato. 8. Agora o arquivo existe na branch principal também!

Módulo 2 – Estruturas de Controle

Aula 05 – Resolução de Conflitos

🎯 Objetivos de Aprendizagem

Entender o que é um conflito de merge (Merge Conflict).
Identificar quando e por que conflitos acontecem.
Aprender a ler os marcadores de conflito (<<<<<<<, =======, >>>>>>>).
Resolver conflitos manualmente e finalizar o merge.

📚 Conteúdo

1. O que é um Conflito?

O Git é muito inteligente. Se duas pessoas alterarem arquivos diferentes, ou até partes diferentes do MESMO arquivo, ele consegue unir (merge) tudo sozinho. Porém, se duas pessoas alterarem a mesma linha de formas diferentes, o Git entra em pânico: "Qual das duas versões eu devo manter?". Isso é um conflito.

2. Identificando um Conflito

Quando você tenta fazer um git merge e dá conflito, o Git avisa: CONFLICT (content): Merge conflict in arquivo.txt. O git status mostrará o arquivo como both modified.

3. Anatomia de um Conflito

Dentro do arquivo, o Git adiciona marcadores especiais:

<<<<<<< HEAD
Texto da minha branch atual (ex: main)
=======
Texto da branch que estou tentando unir (ex: feature)
>>>>>>> feature

Sua missão é: 1. Apagar as linhas <<<<, ====, >>>>. 2. Decidir qual texto fica (ou reescrever um novo texto que combine os dois). 3. Salvar.

4. Finalizando

Depois de editar e salvar: 1. git add arquivo.txt (Isso diz ao Git: "Resolvi!"). 2. git commit (Sem mensagem, ele abrirá um editor com uma mensagem padrão de merge, basta salvar e sair).

📽 Roteiro de Slides

O Pesadelo do Desenvolvedor Iniciante: A tela CONFLICT.
Por que acontece? (Mexer na mesma linha ao mesmo tempo).
O que o Git faz? (Ele PAUSA o merge e pede ajuda).
Os Símbolos Mágicos:
<<<<<<< (O que eu tenho).
======= (Divisória).
>>>>>>> (O que está chegando).
O Passo a Passo da Resolução: Editar -> Add -> Commit.
Dica de Ouro: Comunique-se com sua equipe para evitar isso!

📝 Quiz

Quando ocorre um conflito de merge?
Como o Git resolve conflitos automaticamente na mesma linha?
O que significam as linhas entre <<<<<<< e =======?
Qual comando usamos para marcar um arquivo como "resolvido"?
O que devemos fazer com os marcadores de conflito (<<<<, ====, >>>>)?

Gabarito

1: B 2: D 3: A 4: C 5: A

🛠 Exercícios

Prepare o Terreno: Crie um repo novo conflito-sandbox. Crie texto.txt com "Linha 1: Original" e commite.
Branch A: Crie branch modificacao-a. Mude para ela. Mude o texto para "Linha 1: Modificação A". Commite.
Branch B: Volte para a main. Mude o arquivo para "Linha 1: Modificação B". Commite.
O Caos: Tente fazer git merge modificacao-a. Veja o conflito acontecer!
A Solução: Abra o arquivo, escolha qual frase manter, apague os marcadores, salve, faça git add e git commit.

🚀 Projeto da Aula

No meu-portfolio-git: 1. Crie uma branch conflito-proposital. 2. Mude o título no sobre.txt. Commite. 3. Volte para a main. 4. Mude o MESMO título no sobre.txt para algo diferente. Commite. 5. Tente mergear. 6. Resolva o conflito escolhendo o melhor título e finalizando o merge. Parabéns, você é um pacificador de código!

Aula 06 – Introdução ao GitHub

🎯 Objetivos de Aprendizagem

Navegar pela interface do GitHub.
Configurar um perfil profissional.
Entender os principais conceitos da plataforma: Stars, Forks, Watch e Issues.
Diferenciar repositórios públicos e privados.

📚 Conteúdo

1. O GitHub como Portfólio

O GitHub não é apenas um lugar para guardar código; é a principal rede social profissional para desenvolvedores. - Perfil: Seu "currículo" vivo. Mostra seus projetos, tecnologias e frequência de trabalho. - Gráfico de Contribuição (Heatmap): Aqueles quadradinhos verdes que mostram o quanto você está ativo.

2. Explorando a Interface

Dashboard: Sua página inicial com novidades de quem você segue.
Repositório: A "casa" de um projeto. Contém o código, documentação (README), discussões (Issues) e propostas de mudança (Pull Requests).

3. Conceitos Sociais

Star (Estrela): É o "curtir" do GitHub. Salva o projeto nos seus favoritos.
Watch (Observar): Você receberá notificações sobre tudo o que acontecer naquele projeto.
Fork (Garfo/Bifurcação): Copia o projeto de outra pessoa para a SUA conta, para que você possa modificá-lo livremente sem afetar o original.

4. Issues (Problemas/Tarefas)

Issues são usadas para: - Relatar bugs. - Pedir novas funcionalidades. - Discutir ideias. - Organizar tarefas (To-Do list).

📽 Roteiro de Slides

GitHub != Git (Revisão).
O Perfil do Desenvolvedor: Bio, Foto, Pinned Repos.
O Heatmap: Por que os recrutadores olham?
Anatomia de um Repositório: Code, Issues, PRs, Wiki.
Interações: Star vs Watch vs Fork.
Issues: A ferramenta de gestão de projetos embutida.

📝 Quiz

Para que serve o botão "Star" em um repositório?
O que o "Fork" faz?
O que são "Issues"?
Onde vejo a frequência de contribuições de um usuário?
Repositórios privados podem ser vistos por qualquer pessoa?

Gabarito

1: B 2: A 3: C 4: D 5: B

🛠 Exercícios

Perfil: Acesse seu perfil no GitHub. Adicione uma foto profissional e uma bio curta (ex: "Desenvolvedor em formação | Apaixonado por Python").
Exploração: Procure por um projeto famoso (ex: facebook/react, microsoft/vscode ou fastapi/fastapi).
Interação: Dê uma "Star" nesse projeto para tê-lo em sua lista de favoritos.
Follow: Siga algum desenvolvedor relevante (pode ser o criador da linguagem que você estuda).

🚀 Projeto da Aula

No projeto meu-portfolio-git (local), não faremos nada técnico hoje. Mas, na próxima aula, vamos subir esse projeto para o GitHub! Por enquanto, garanta que sua conta no GitHub está bonita e organizada. - Verifique se seu nome de usuário é adequado. - Verifique se seu email está confirmado. - (Opcional) Ative a autenticação de dois fatores (2FA) para segurança.

Aula 07 – Criando e gerenciando repositórios no GitHub

🎯 Objetivos de Aprendizagem

Criar um novo repositório no GitHub.
Conectar um repositório local a um remoto (git remote add).
Enviar alterações para a nuvem (git push).
Baixar projetos existentes (git clone).
Entender o arquivo .gitignore.

📚 Conteúdo

1. Criando um Repositório Remoto

No GitHub, clique no botão New (ou + no canto superior direito). - Dê um nome (ex: meu-primeiro-repo). - Escolha Público ou Privado. - (Opcional) Inicializar com README, .gitignore ou License.

2. Conectando Local e Remoto

Se você já tem um repo local (como nosso portfólio), conecte-o assim:

git remote add origin https://github.com/SEU-USUARIO/NOME-DO-REPO.git

- origin: É apenas um apelido padrão para o link do repositório remoto.

3. Enviando Alterações (Push)

Para enviar seus commits locais para o servidor:

git push -u origin main

- -u: Configura o vínculo (upstream) para que nos próximos pushes você possa digitar apenas git push.

4. Baixando Projetos (Clone)

Para baixar um projeto completo do GitHub para seu computador:

git clone https://github.com/usuario/projeto.git

Isso cria uma pasta com todo o histórico do projeto.

5. Ignorando Arquivos (.gitignore)

Nem tudo deve ir para o Git (senhas, arquivos temporários, pastas de build). Crie um arquivo chamado .gitignore e liste o que o Git deve ignorar:

.env
node_modules/
*.log

📽 Roteiro de Slides

Local vs Remoto: Conceito chave.
Criando o "Balde" na Nuvem (New Repo).
O Elo de Ligação: git remote add origin URL.
O Envio: git push (Empurrar).
O Download: git clone (Clonar).
A Importância do .gitignore (Não suba lixo nem senhas!).

📝 Quiz

Qual comando envia commits locais para o GitHub?
O que é "origin" no comando git push origin main?
Qual comando copia um repositório inteiro do GitHub para sua máquina?
Para que serve o arquivo .gitignore?
Se eu quiser baixar apenas as atualizações de um repo já clonado, usaria clone novamente?

Gabarito

1: C 2: B 3: A 4: D 5: B (Não, usaria git pull - spoiler da próxima aula, mas a resposta certa é "Não").

🛠 Exercícios

GitHub: Crie um repositório chamado teste-remoto. Não marque nenhuma opção (README, gitignore).
Local: Crie uma pasta teste-local, inicie o git, crie um arquivo e commite.
Link: Adicione o remote (git remote add origin ...).
Push: Envie (git push -u origin main).
Confira: Recarregue a página do GitHub e veja seu arquivo lá!

🚀 Projeto da Aula

Agora é a hora da verdade para o meu-portfolio-git.

Vá no GitHub e crie um novo repositório chamado portfolio-dev.
Não marque nenhuma opção de inicialização (README, etc). Crie o repo vazio.
Copie o link HTTPS fornecido (ex: https://github.com/seu-user/portfolio-dev.git).
No terminal do seu projeto local:
```
git remote add origin COLAR_O_LINK_AQUI
git branch -M main
git push -u origin main
```
(Pode pedir login/senha. Se usar HTTPS, pode precisar de um Token ou Git Credential Manager).
Vá ao GitHub e veja: Seu portfólio está online!

Aula 08 – Pull Requests e Code Review

🎯 Objetivos de Aprendizagem

Entender o fluxo de Pull Request (PR).
Aprender como sugerir mudanças em projetos.
Realizar um Code Review básico.
Finalizar (Merge) um PR pela interface do GitHub.

📚 Conteúdo

1. O que é um Pull Request (PR)?

Se você trabalha em branches isoladas (como aprendemos na Aula 04), como você avisa sua equipe que terminou e que suas mudanças estão prontas para entrar na main? Você cria um Pull Request. Traduzindo: "Por favor, puxe (pull) minhas alterações".

2. O Ciclo de Vida do PR

Push: Você envia sua branch para o GitHub.
Open PR: No site, você clica em "Compare & pull request".
Review: Seus colegas leem seu código, comentam e sugerem melhorias.
Approve: Se tudo estiver ok, um colega aprova.
Merge: O código é fundido à branch principal.

3. Code Review (Revisão de Código)

É a prática de ler o código do outro antes de aceitar. - Não é crítica pessoal: É sobre a qualidade do código. - Benefícios: - Encontra bugs antes de ir para produção. - O time todo aprende novas formas de resolver problemas. - Mantém o padrão de qualidade.

4. Merge via GitHub

Diferente do git merge no terminal (que é local), o merge do PR acontece no servidor do GitHub. Depois, todos do time fazem git pull para baixar a novidade.

📽 Roteiro de Slides

O Coração da Colaboração: Pull Requests.
Fluxo: Branch -> Push -> PR -> Review -> Merge.
A Interface do PR no GitHub:
Aba "Conversation": Discussão geral.
Aba "Files changed": Onde o review acontece linha a linha.
Code Review: Como ser educado e eficiente.
Tipos de Merge no GitHub:
Create a merge commit (Padrão).
Squash and merge (Junta tudo em um só).
Rebase and merge (Avançado).

📝 Quiz

Qual o primeiro passo para criar um Pull Request?
Para que serve a aba "Files changed" em um PR?
O que é Code Review?
Quem deve fazer o merge de um PR idealmente?
Após o merge no GitHub, o que os outros desenvolvedores devem fazer?

Gabarito

1: B ("Push da branch") 2: A 3: C 4: D (Outra pessoa, após aprovar) 5: B (git pull)

🛠 Exercícios

Prepare: Crie uma branch feature-pr no seu repo de teste.
Mude: Adicione um arquivo pr.txt.
Envie: git push -u origin feature-pr.
GitHub: Vá ao repo no navegador. Você verá um botão amarelo "Compare & pull request". Clique.
PR: Escreva um título e descrição. Clique em "Create pull request".
Simule Review: Vá em "Files changed", clique no + ao lado de uma linha e adicione um comentário para você mesmo.
Merge: Volte para "Conversation", clique em "Merge pull request" e depois "Confirm merge".

🚀 Projeto da Aula

No portfolio-dev: 1. Crie uma branch chamada melhoria-readme. 2. Edite o arquivo sobre.txt (ou crie um README.md se quiser adiantar) adicionando mais skills. 3. Envie para o GitHub: git push -u origin melhoria-readme. 4. Abra o PR no GitHub. 5. Como você não tem um time, você mesmo vai revisar e "Mergear". 6. Veja como a branch melhoria-readme foi deletada (opcional) e a main agora tem suas mudanças. 7. Importante: No seu terminal local, volte para a main e digite git pull para baixar essas mudanças que agora estão na nuvem!

Módulo 3 – Funções e Modularização

Aula 09 – Fluxo de trabalho com GitHub Flow

🎯 Objetivos de Aprendizagem

Entender a importância de seguir um fluxo de trabalho padronizado.
Aprender o GitHub Flow: um modelo simples e eficaz para projetos ágeis.
Diferenciar GitHub Flow de Git Flow (mais complexo).
Compreender o ciclo: Branch -> Commit -> PR -> Merge -> Deploy.

📚 Conteúdo

1. O que é um Workflow?

Um workflow (fluxo de trabalho) é um conjunto de regras que a equipe combina para evitar o caos. Sem regras: "Vou commitar na main", "Vou criar a branch teste-do-joao", "Vou mergear sem PR". Com regras: "Toda mudança precisa de branch", "A main é sagrada", "Só mergeia com aprovação".

2. O GitHub Flow

É o modelo recomendado pelo GitHub e usado por empresas modernas. Ele tem regras simples: 1. A branch main é sempre estável e pronta para ir ao ar (Deploy). 2. Para qualquer tarefa (nova feature ou bugfix), crie uma branch descritiva a partir da main. 3. Commite suas mudanças nessa branch. 4. Abra um Pull Request para discutir o código. 5. Após aprovação, faça o Merge na main. 6. Imediatamente após o merge, a main é atualizada em produção (Deploy).

3. GitHub Flow vs Git Flow

Git Flow: Modelo antigo (2010), complexo, com branches develop, release, hotfix, tags... Bom para softwares "em caixa" com versões semestrais.
GitHub Flow: Leve, contínuo, focado em web/SaaS e entrega rápida. É o que vamos focar.

📽 Roteiro de Slides

O Caos sem Regras.
Apresentando: GitHub Flow.
Regra #1: A main é intocável e sempre funciona.
O Ciclo de 6 Passos:
Create Branch.
Add Commits.
Open PR.
Discuss & Review.
Deploy (Teste).
Merge.
Comparação Visual: GitHub Flow (linha reta com galhos curtos) vs Git Flow (teia de aranha complexa).

📝 Quiz

No GitHub Flow, a branch main deve estar em qual estado?
Qual a principal diferença para o Git Flow?
O que deve ser feito antes de qualquer mudança de código?
Quando o código deve ir para produção (Deploy) no GitHub Flow?
O que acontece com a branch de feature após o merge?

Gabarito

1: B ("Sempre pronta para deploy") 2: A ("GitHub Flow é mais simples") 3: C ("Criar uma nova branch") 4: D ("Assim que o merge na main ocorre") 5: B ("Ela pode ser deletada")

🛠 Exercícios

Desenhar o Fluxo: Pegue papel e caneta. Desenhe o fluxo do GitHub Flow. (Main -> Branch -> Commits -> PR -> Merge -> Main).
Simulação Completa:
git switch main -> git pull (Garanta estar atualizado).
git switch -c fix-typo.
Corrija um erro de digitação proposital em qualquer arquivo.
git push origin fix-typo.
Abra o PR.
Merjeie.
Delete a branch.

🚀 Projeto da Aula

No portfolio-dev: 1. Vamos aplicar o GitHub Flow para adicionar uma seção de "Tecnologias". 2. Crie branch feature-techs. 3. No arquivo sobre.txt, adicione: "Tecnologias: Git, GitHub, Markdown". 4. Envie, abra PR, aprove. 5. Importante: No GitHub Flow, merges são frequentes. Não acumule trabalho de semanas. Tente mergear coisas pequenas todo dia.

Aula 10 – Issues e projetos no GitHub

🎯 Objetivos de Aprendizagem

Aprender a registrar e organizar tarefas com Issues.
Utilizar Labels, Assignees e Milestones para classificar trabalho.
Gerenciar o fluxo de trabalho visualmente com GitHub Projects (Kanban).
Conectar Issues com Pull Requests.

📚 Conteúdo

1. Issues: O Centro de Comando

Issues não são apenas para "problemas". Elas representam qualquer trabalho a ser feito. - Bug: "Botão de login não funciona." - Feature: "Adicionar suporte a pagamentos via Pix." - Task: "Atualizar documentação."

2. Anatomia de uma Issue

Title: Resumo claro.
Description: Detalhes, passos para reproduzir, imagens.
Assignees: Quem é o responsável? (Pode ser você).
Labels: Etiquetas coloridas (bug, enhancement, documentation, good first issue).
Milestones: Marcos de entrega (ex: Versão 1.0, Lançamento Beta).

3. GitHub Projects (O Kanban)

Issues em lista são difíceis de visualizar. Projects transformam issues em cartões em um quadro (Board). - Todo: A fazer. - In Progress: Fazendo. - Done: Feito. Isso dá visibilidade instantânea do status do projeto.

4. Fechamento Automático

Se você escrever Closes #123 na descrição de um Pull Request, o GitHub fechará a Issue #123 automaticamente quando o PR for mergeado. Mágica pura!

📽 Roteiro de Slides

Gerenciamento de Projetos: Como não se perder.
Issues: A unidade atômica de trabalho.
Etiquetas (Labels): Organização visual.
GitHub Projects: O Trello embutido no GitHub.
Automação: "Closes #issue-number" no PR.
Boas práticas de descrição de Issues.

📝 Quiz

Qual a função do campo "Assignee" em uma Issue?
Para que servem as "Labels"?
O que acontece se eu usar a palavra-chave "Closes #10" num Pull Request?
O GitHub Projects permite visualizar as tarefas em qual formato popular?
Issues servem apenas para reportar bugs (erros)?

Gabarito

1: B ("Definir o responsável pela tarefa") 2: A ("Categorizar e filtrar issues") 3: C ("A Issue #10 é fechada automaticamente após o merge") 4: A ("Kanban / Quadro") 5: B ("Não, servem para features e discussões também")

🛠 Exercícios

Criar Issue: Vá no portfolio-dev, aba Issues, "New Issue". Título: "Adicionar seção de Contato". Descrição: "Precisamos de um email visível no rodapé".
Categorizar: Adicione a Label "enhancement" e se coloque como Assignee.
Criar Projeto: Aba Projects > New Project. Escolha "Board".
Adicionar Item: Adicione sua Issue ao projeto.
Mover: Arraste o cartão da coluna "Todo" para "In Progress".

🚀 Projeto da Aula

Hoje vamos organizar o futuro do portfolio-dev. 1. Crie 3 Issues reais para melhorias futuras: - "Melhorar CSS da página inicial". - "Adicionar foto de perfil real". - "Traduzir para Inglês". 2. Crie um Project chamado "Roadmap 2026". 3. Adicione as 3 issues ao quadro. 4. Experimente criar uma Issue direto de dentro do projeto (convertendo um rascunho em issue). 5. Deixe tudo na coluna "Todo", pois ainda não começamos a trabalhar nelas.

Módulo 4 – Arquivos e Exceções

Aula 11 – Boas práticas de commits e versionamento

🎯 Objetivos de Aprendizagem

Escrever mensagens de commit claras e úteis.
Entender o conceito de Commit Atômico.
Conhecer o padrão Conventional Commits.
Evitar erros comuns (commits gigantes, mensagens vagas).

📚 Conteúdo

1. Mensagens de Commit Importam

Imagine ler um histórico assim: - correção - arrumando - teste - final Isso não ajuda ninguém. O objetivo da mensagem de commit é explicar o PORQUÊ da mudança.

2. A Regra do Imperativo

No Git, a convenção é usar o verbo no imperativo presente (como se você estivesse dando uma ordem ao código). - Ruim: "Adicionado botão de login" (Passado) ou "Adicionando botão" (Gerúndio). - Bom: "Adiciona botão de login" (Imperativo). Dica: A mensagem deve completar a frase: "Se eu aplicar este commit, ele irá..." -> "Adicionar botão de login".

3. Commits Atômicos

Um commit deve fazer uma única coisa. Se você corrigiu um bug no login E mudou a cor do rodapé: - Errado: git commit -m "Arruma login e muda cor" (Misturou assuntos). - Certo: Faça dois commits separados. Isso facilita reverter uma mudança sem afetar a outra.

4. Conventional Commits

Um padrão muito usado na indústria: - feat: adiciona filtro de busca (Nova feature). - fix: corrige erro de cálculo (Correção de bug). - docs: atualiza readme (Documentação). - style: formata código (Espaços, pontuação). - refactor: melhora performance (Sem mudar funcionalidade).

📽 Roteiro de Slides

O Hall da Vergonha: "wip", "fix", "bug".
A Estrutura Ideal: Título (50 chars) + Corpo (Opcional).
O Modo Imperativo: "Adiciona", "Remove", "Corrige".
Commit Atômico: Pequeno e focado.
Padrões de Mercado: Conventional Commits (feat:, fix:).
Por que isso ajuda no Code Review?

📝 Quiz

Qual é a convenção gramatical recomendada para mensagens de commit em português?
O que é um "Commit Atômico"?
Qual desses prefixos indica uma nova funcionalidade no padrão Conventional Commits?
Por que não devemos misturar correções de bugs com formatação de código no mesmo commit?
Qual mensagem é a mais adequada?

Gabarito

1: B ("Imperativo Presente") 2: A ("Um commit que resolve apenas uma tarefa específica") 3: C ("feat:") 4: D ("Porque dificulta o review e a reversão de mudanças específicas") 5: C ("fix: corrige erro de validação no formulário")

🛠 Exercícios

Analise o Histórico: Dê git log no seu projeto. Suas mensagens seguem o padrão? (Provavelmente não, e tudo bem, estamos aprendendo).
Prática de Amend:
Faça uma alteração qualquer e commite com a mensagem "erro".
Ops! Mensagem ruim.
Use git commit --amend -m "fix: corrige erro de digitação" para reescrever o ÚLTIMO commit sem criar um novo.
Cuidado: Só faça isso se ainda não deu Push!
Divisão:
Faça duas alterações diferentes (ex: crie a.txt e b.txt).
Tente commitar a.txt primeiro (git add a.txt, git commit).
Depois commite b.txt.
Isso é atomicidade.

🚀 Projeto da Aula

Vamos limpar o histórico futuro do portfolio-dev. 1. Escolha uma tarefa pequena do seu Project Board (ex: Criar arquivo de Estilos ou atualizar Texto). 2. Crie a branch. 3. Faça a mudança. 4. Na hora de commitar, use o padrão Conventional Commit. Ex: feat: adiciona seção de projetos no readme 5. Veja como fica bonito no histórico do GitHub.

Aula 12 – README profissional e Markdown

🎯 Objetivos de Aprendizagem

Entender a importância de um bom README.md.
Aprender a sintaxe básica e intermediária do Markdown.
Criar documentação atraente para seus projetos.
Usar Badges e Emojis para enriquecer visualmente.

📚 Conteúdo

1. O Cartão de Visitas

Quando alguém abre seu repositório, a primeira coisa que vê é o README.md. Se ele estiver vazio ou ruim, supõe-se que o projeto é ruim. Um bom README responde: - O que é isso? - Para que serve? - Como instalo/uso?

2. Markdown: A Linguagem da Web

O .md significa Markdown. É uma linguagem de marcação leve que o GitHub converte em HTML bonito. Principais códigos: - # Título 1 (H1) - ## Título 2 (H2) - **Negrito** - [Texto do Link](URL) - ![Texto da Imagem](URL-da-Imagem) - - Item de lista

3. Estrutura Ideal de um README

Título e Badges: Nome do projeto e status (build passing, license, version).
Descrição: Resumo de 2 linhas.
Features: O que o projeto faz.
Instalação: Passos para rodar.
Tecnologias: Ícones ou lista das langs usadas.
Autor/Licença.

📽 Roteiro de Slides

"Ninguém lê código, todos leem documentação".
O poder do Markdown: Simples e poderoso.
Sintaxe Rápida:
Títulos (# -> ####)
Listas (- ou 1.)
Código (```)
Badges: O que são aquelas "medalhas" coloridas? (Shields.io).
GIFs e Imagens: Uma imagem vale mais que 1000 linhas de código.

📝 Quiz

Qual caractere é usado para criar títulos em Markdown?
Como se escreve um texto em negrito?
Qual a diferença entre link e imagem na sintaxe?
Para criar um bloco de código de várias linhas, o que usamos?
Qual serviço popular gera badges (escudos) para READMEs?

Gabarito

1: B ("#") 2: A ("Texto") 3: C ("A imagem tem um ! na frente") 4: D ("Três crases ```") 5: B ("Shields.io")

🛠 Exercícios

Markdown Playground: Vá em dillinger.io ou use o próprio editor do GitHub (Preview) para testar.
Criando um README:
Título: # Meu Portfólio.
Subtítulo: ## Sobre mim.
Lista: - HTML, - CSS, - Git.
Link: [Meu LinkedIn](url).
Código:
```
print("Hello World")
```

🚀 Projeto da Aula

Vamos profissionalizar o portfolio-dev AGORA. 1. Crie uma branch docs-readme. 2. Delete o sobre.txt (sim, delete). 3. Crie o arquivo README.md (Maiúsculas importam!). 4. Cole o seguinte template e preencha com seus dados:

# 🚀 Portfólio de [Seu Nome]

Bem-vindo ao meu portfólio oficial! Aqui você encontra meus projetos e estudos.

## 🛠 Tecnologias
- Git & GitHub
- [Linguagem favorita]
- [Outra skill]

## 📫 Contato
- Email: [seu@email.com]
- LinkedIn: [link]

Commite (feat: adiciona readme profissional), Push, PR e Merge.
Vá na página inicial do repo e veja a mágica acontecer!

Módulo 5 – Programação Orientada a Objetos

Aula 13 – Trabalhando em Equipe

🎯 Objetivos de Aprendizagem

Entender os níveis de permissão no GitHub.
Adicionar colaboradores ao seu repositório.
Compreender a diferença entre Colaborador (Time) e Contribuidor (Comunidade).
Simular um fluxo de trabalho em par.

📚 Conteúdo

1. Níveis de Permissão

Por padrão, só você (Owner) pode alterar seu repositório. Para trabalhar com amigos ou colegas, você precisa dar permissão. Vá em Settings > Collaborators > Add people.

2. Colaborador vs Contribuidor

Colaborador: Tem permissão de escrita ("Write Access"). Pode dar push direto, criar branches no repo oficial e mergir PRs. É alguém "de casa".
Contribuidor: Não tem permissão. Ele faz um Fork, altera no repo dele e manda um Pull Request de lá. É alguém "de fora".

3. O Fluxo de Equipe

Quando você tem um time: 1. Todos clonam o mesmo repositório. 2. Cada um cria sua branch (feature-joao, feature-maria). 3. Todos abrem PRs para a main. 4. Todos revisam o código de todos.

4. Mantendo-se Atualizado

Antes de começar a trabalhar, a Regra de Ouro é:

git pull origin main

Isso evita que você trabalhe em cima de código velho e tenha conflitos depois.

📽 Roteiro de Slides

O Mito do "Lobo Solitário".
Configurando o Time: Settings > Collaborators.
Permissões: Read (Ler), Write (Escrever), Admin (Mandar).
O Perigo: Colaboradores podem deletar branches (e até o repo, se for Admin). Cuidado!
Fluxo de Fork (Open Source) vs Fluxo de Colaborador (Empresa).
A importância do git pull diário.

📝 Quiz

Qual menu do GitHub usamos para adicionar pessoas ao projeto?
Um "Colaborador" precisa fazer Fork do projeto para contribuir?
Qual a diferença principal entre Owner e Colaborador?
O que acontece se seu colega der push na main e você tentar dar push também sem atualizar antes?
Qual comando baixa as atualizações do time para o seu computador?

Gabarito

1: B ("Settings > Collaborators") 2: B ("Não, ele tem acesso direto") 3: C ("O Owner pode deletar o repositório") 4: A ("O Git rejeita seu push pedindo para fazer pull primeiro") 5: C ("git pull")

🛠 Exercícios

Adicionar Amigo (Simulação):
Vá em Settings > Collaborators.
Clique em "Add people".
Digite o usuário de um amigo (ou uma conta secundária sua).
Ele receberá um convite por email.
O Erro do Push Rejeitado:
Para simular um colega trabalhando: Vá no GitHub e edite o README direto no navegador. Commite lá ("Simula mudança do colega").
Volte pro terminal local. Faça uma mudança no README e tente dar Push.
Erro! Updates were rejected because the remote contains work that you do not have locally.
Solução: git pull. Resolva o conflito (se houver). Dê push de novo.

🚀 Projeto da Aula

No seu portfolio-dev: 1. Convide um "colaborador fantasma" (pode ser um amigo ou apenas simule o processo). 2. Adicione uma seção no README:

## 🤝 Colaboradores
Obrigado às seguintes pessoas que contribuíram para este projeto:
- @seu-usuario

3. Use o exercício 2 acima para praticar o git pull antes de enviar essa mudança.

Aula 14 – GitHub Pages e Portfólio

🎯 Objetivos de Aprendizagem

Entender o que é o recurso GitHub Pages.
Transformar um repositório de código em um site publicado na internet.
Compreender as limitações (apenas sites estáticos).
Publicar seu portfólio para o mundo.

📚 Conteúdo

1. Seu Código na Web

Até agora, seu portfólio é apenas uma pasta de arquivos. O GitHub Pages é um serviço de hospedagem gratutita que pega seus arquivos HTML, CSS e JS e os publica em um endereço como seu-usuario.github.io/seu-projeto.

2. O que é "Estático"?

O Pages serve sites estáticos. - Funciona: HTML, CSS, JavaScript, Imagens, React (buildados), Vue, Angular. - Não Funciona: PHP, Python (Django/Flask), Node.js (backend), Banco de Dados (MySQL). Para portfólios, blogs e documentações, ele é perfeito.

3. Configuração

Basta ir em Settings > Pages. Em "Build and deployment", escolha "Deploy from a branch". Selecione a branch main e a pasta / (root). Clique em Save.

4. O Arquivo index.html

Para que o site funcione, a primeira página DEVE se chamar index.html. Se não existir, o GitHub mostrará o README (se configurado) ou um erro 404.

📽 Roteiro de Slides

O sonho do site próprio (Grátis!).
Diferença entre Repositório (Código) e Site (Produto Final).
Limitações: Sem Backend (PHP, SQL).
O passo a passo da ativação.
O endereço mágico: username.github.io.
Personalização: Temas automáticos (Jekyll).

📝 Quiz

O GitHub Pages é um serviço gratuito?
Posso hospedar um site feito em PHP com banco de dados MySQL no GitHub Pages?
Qual é o nome obrigatório do arquivo principal para que a página inicial carregue?
Em qual menu do repositório ativamos o GitHub Pages?
Quanto tempo demora para o site ir ao ar após o push?

Gabarito

1: A ("Sim, para repos públicos e privados selecionados") 2: B ("Não, ele só aceita conteúdo estático") 3: C ("index.html") 4: D ("Settings > Pages") 5: B ("Alguns segundos ou poucos minutos")

🛠 Exercícios

Hello World: Crie um arquivo index.html básico no seu repo de teste, com <h1>Olá Mundo</h1>.
Ativação: Vá nas configurações desse repo e ative o Pages.
Acesso: Aguarde a bolinha ficar verde na aba "Actions" ou recarregue a página de configurações para ver o link. Clique e veja seu site no ar!

🚀 Projeto da Aula

Vamos transformar o portfolio-dev em um site de verdade.

Delete o arquivo sobre.txt (se ainda existir). O README.md vamos manter.
Crie um arquivo index.html na raiz do projeto.

Cole este código (ou faça o seu melhor):

<!DOCTYPE html>
<html>
<head>
    <title>Portfólio Dev</title>
    <style>
        body { font-family: sans-serif; text-align: center; padding: 50px; }
        h1 { color: #2c3e50; }
        p { color: #7f8c8d; }
    </style>
</head>
<body>
    <h1>Olá, eu sou [Seu Nome]</h1>
    <p>Desenvolvedor apaixonado por Git e GitHub.</p>
    <a href="https://github.com/seu-usuario">Meu GitHub</a>
</body>
</html>

Commite e Push (feat: adiciona site do portfólio).
Vá no GitHub, Settings > Pages, Ative na main.
Aguarde alguns instantes e acesse o link gerado.
Parabéns! Você tem um site profissional. Mande o link para seus amigos!

Módulo 6 – Ecossistema

Aula 15 – Erros comuns e como resolver

🎯 Objetivos de Aprendizagem

Identificar e corrigir os erros mais frequentes do dia a dia.
Entender o que é um estado de Detached HEAD.
Resolver commits feitos na branch errada (git reset).
Recuperar arquivos deletados acidentalmente.

📚 Conteúdo

1. Detached HEAD (Cabeça Desconectada)

Acontece quando você faz git checkouk <HASH-DO-COMMIT> em vez de nome de branch. Você viaja no tempo para ver aquele commit, mas não está "segurando" em nenhuma branch. Se commitar aqui, o commit ficará perdido no limbo quando você voltar para a main. Solução: git switch main (para voltar) ou git switch -c nova-branch (para salvar o estado atual em uma nova branch).

2. Push Rejected (Non-fast-forward)

Erro: ! [rejected] main -> main (fetch first) Causa: Alguém (ou você mesmo em outro PC) enviou commits para o servidor que você não tem. Solução: git pull origin main (Baixe primeiro, resolva conflitos se houver, depois envie).

3. Commitei na Branch Errada!

Você estava na main, mas deveria estar na feature-x. E agora? Solução (Reset Suave): 1. git reset --soft HEAD~1: Desfaz o último commit, mas MANTÉM os arquivos modificados na sua área de stage (verde). 2. git switch -c feature-x: Cria/Muda para a branch certa levando as mudanças junto. 3. git commit -m "mensagem": Commita de novo no lugar certo.

📽 Roteiro de Slides

O Pânico do Iniciante.
"Socorro, perdi meu código!" (Spoiler: É difícil perder coisas no Git).
Detached HEAD: Você está no limbo. Como sair?
Reset: Soft vs Hard.
Soft: "Oops, volte um passo mas guarde meu trabalho."
Hard: "Delete tudo e volte para o passado (Perigoso!)."
O Reflog: A caixa preta do avião (Recuperando o irrecoverável).

📝 Quiz

O que significa estar em "Detached HEAD"?
Qual comando desfaz o último commit mas mantém seus arquivos modificados prontos para commitar de novo?
Se o git push for rejeitado por "non-fast-forward", o que você deve fazer?
O comando git reset --hard é seguro para usar indiscriminadamente?
Qual comando mostra um histórico de TUDO o que você fez no terminal (inclusive resets e checkouts)?

Gabarito

1: C ("Você não está em nenhuma branch, apenas visitando um commit específico") 2: A ("git reset --soft HEAD~1") 3: B ("Dar git pull primeiro") 4: D ("Não, ele apaga as mudanças não commitadas permanentemente") 5: C ("git reflog")

🛠 Exercícios

Provocando Detached HEAD:
Dê git log --oneline. Copie o hash de um commit antigo.
Dê git checkout <HASH>.
Veja o Git avisar: "You are in 'detached HEAD' state".
Crie um arquivo fantasma.txt. Commite.
Volte para a main: git switch main.
Veja que o fantasma.txt sumiu e o commit "se perdeu". (Ele pode ser recuperado com Reflog, mas isso é papo de sênior).
Salvando commit errado:
Faça uma mudança na main que deveria ser numa branch.
Commite.
Use git reset --soft HEAD~1.
Veja que o arquivo voltou para o Staging (verde).
Crie a branch certa e commite lá. Ufa!

🚀 Projeto da Aula

No seu portfolio-dev: 1. Simule um erro. Delete o index.html sem querer. 2. Dê git status. Ele diz deleted: index.html. 3. Para recuperar: git restore index.html (ou git checkout index.html). 4. Ufa, o arquivo voltou intacto. O Git é seu anjo da guarda.

Aula 16 – Carreira, portfólio e próximos passos

🎯 Objetivos de Aprendizagem

Entender como o GitHub impulsiona sua carreira.
Aprender a contribuir com projetos Open Source.
Conhecer conceitos avançados para estudar a seguir (CI/CD, Actions).
Revisão geral do curso.

📚 Conteúdo

1. O GitHub como Currículo

Recrutadores buscam: - Consistência: O "paredão verde" (heatmap) mostra hábito de codar. - Qualidade: Projetos com README, código limpo e commits organizados. - Colaboração: PRs em outros projetos, issues abertas e discussões.

2. Open Source

Software de Código Aberto move o mundo. - Como começar: Procure issues com a label good first issue ou help wanted. - Hacktoberfest: Evento anual (Outubro) que incentiva contribuições.

3. Próximos Passos (O que estudar?)

Você dominou o básico. O que vem agora? - GitHub Actions (CI/CD): Automação de testes e deploy a cada push. - Git Hooks: Scripts que rodam antes do commit (ex: linters). - Git Rebase: Uma forma mais limpa (e perigosa) de fazer merge. - Conventional Commits: Aprofundar no padrão.

4. Encerramento

Você saiu do zero, instalou o Git, aprendeu comandos de terminal, conectou com a nuvem, trabalhou em branches, resolveu conflitos, fez code review e publicou um site. Você agora é um desenvolvedor que sabe versionar código. Parabéns!

📽 Roteiro de Slides

A Jornada do Herói: De copia_final.doc para git push.
Dicas de Carreira: Pinned Repos, Bio clara.
O Mundo Open Source: Não tenha medo de errar.
CI/CD: A esteira automática.
Obrigado e Sucesso!

📝 Quiz

O que geralmente indica a label good first issue em um projeto Open Source?
O que é Hacktoberfest?
O que significa CI/CD (Conceito básico)?
Qual a melhor maneira de mostrar consistência no GitHub?
Qual comando reescreve o histórico de forma linear (alternativa ao merge)?

Gabarito

1: B ("Tarefa adequada para iniciantes") 2: C ("Evento global de incentivo ao Open Source em Outubro") 3: A ("Integração e Entrega Contínuas - Automação") 4: D ("Manter o gráfico de contribuições (heatmap) ativo") 5: B ("git rebase")

🛠 Exercícios

Faxina Final: Entre no seu GitHub. Arquive repositórios de teste (teste-git, etc) ou delete-os. Deixe apenas os projetos bons visíveis.
Pinned: Escolha seus 6 melhores projetos (o portfolio-dev deve ser um deles) e "Pinet" (fixe) no seu perfil.
Star: Dê uma estrela no repositório oficial do Git (git/git) em homenagem ao curso.

🚀 Projeto da Aula

O portfolio-dev está pronto, no ar e lindo. Última missão: 1. Crie uma Issue final no seu repo: "Planejar próximos estudos". 2. Liste o que você quer aprender em 2026. 3. Adicione ao seu Project Board. 4. Mantenha esse repo vivo. Cada projeto novo que você fizer, adicione o link nele. Ele é sua casa na internet.

Materiais

Bem-vindo à seção de materiais complementares do curso. Aqui você encontra recursos adicionais para apoiar seus estudos.

Slides
- Acesse os slides de todas as aulas para revisão.
Exercícios
- Pratique com listas de exercícios para cada módulo.
Quizzes
- Teste seus conhecimentos com quizzes interativos.
Projetos
- Desenvolva projetos práticos para aplicar o que aprendeu.
Setup
- Guias de instalação e configuração do ambiente.

Slides

Slides das Aulas

Aqui você encontra os slides de apresentação de cada aula.

Módulo 1 – Fundamentos
Módulo 2 – Estruturas de Controle
Módulo 3 – Funções
- Slide 09 - Funções
- Slide 10 - Módulos e Pacotes
Módulo 4 – Arquivos e Exceções
- Slide 11 - Manipulação de Arquivos
- Slide 12 - Tratamento de Exceções
Módulo 5 – POO
- Slide 13 - Introdução a Classes e Objetos
- Slide 14 - Herança e Polimorfismo
Módulo 6 – Ecossistema
- Slide 15 - APIs e Requisições HTTP
- Slide 16 - Testes e Boas Práticas

Como Usar

Os slides usam RevealJS para apresentação interativa
Clique nos links acima para visualizar em tela cheia
Use as setas do teclado para navegar entre os slides

Exercícios

Bem-vindo à seção de exercícios! Aqui você encontra listas de exercícios práticos para cada aula do curso.

Módulo 1 – Fundamentos
Módulo 2 – Estruturas de Controle
Módulo 3 – Funções
- Exercício 09 - Funções I
- Exercício 10 - Módulos
Módulo 4 – Arquivos e Exceções
- Exercício 11 - Arquivos
- Exercício 12 - Exceções
Módulo 5 – POO
- Exercício 13 - Classes
- Exercício 14 - Herança
Módulo 6 – Ecossistema
- Exercício 15 - APIs
- Exercício 16 - Testes

Dicas

Tente resolver os exercícios sem consultar a solução
Pratique regularmente para fixar o conteúdo
Não tenha medo de errar, faz parte do aprendizado!

Exercícios da Aula 01

🛠 Exercícios

Verificação Inicial:
Abra seu terminal (Prompt de Comando, PowerShell ou Terminal do VS Code).
Digite o comando git --version.
Anote a versão que aparece (ex: git version 2.40.0.windows.1). Se der erro, não se preocupe, instalaremos na próxima aula.
Criação de Conta no GitHub:
Acesse https://github.com.
Clique em "Sign Up".
Siga os passos para criar sua conta gratuita.
Dica: Escolha um nome de usuário (username) profissional, pois ele será o endereço do seu portfólio (ex: github.com/seunome).
Simulação Manual de Versão:
Crie uma pasta na sua Área de Trabalho chamada projeto-manual.
Crie um arquivo texto.txt dentro dela e escreva "Versão 1".
Agora, suponha que você precisa mudar o texto mas quer guardar o original.
Copie o arquivo e renomeie para texto_v2.txt.
Edite o texto_v2.txt escrevendo "Versão 2".
Reflita: Se você tivesse 100 arquivos e 50 versões, como seria gerenciar isso? Esse é o problema que o Git resolve.

Exercícios da Aula 02

🛠 Exercícios

Instalação do Git:
Se ainda não fez, vá em git-scm.com e baixe a última versão.
Siga as instruções de instalação padrão.
Ao final, abra o menu do seu computador e procure por "Git Bash" (Windows) ou "Terminal" (Mac/Linux).
Configuração de Usuário:
No terminal, digite: git config --global user.name "Seu Nome" (Substitua "Seu Nome" pelo seu nome real, mantendo as aspas).
Digite: git config --global user.email "seuemail@gmail.com" (Use seu email real).
Verificação:
Digite git config --list.
Procure nas linhas que aparecem algo como: user.name=Seu Nome user.email=seuemail@gmail.com
Se encontrar, parabéns! Seu Git está pronto para uso.

Exercícios da Aula 03

🛠 Exercícios

Prática de Fluxo Básico:
Crie uma pasta nova chamada exercicio-03.
Inicie o Git nela.
Crie 3 arquivos: a.txt, b.txt, c.txt.
Adicione APENAS o a.txt (git add a.txt).
Faça um commit (git commit -m "Adiciona A").
Veja o status (git status). O que aconteceu com b e c?
Entendendo o Staging:
Adicione b.txt (git add b.txt).
Tente fazer git commit SEM a opção -m. O que acontece? (Dica: ele abre um editor de texto. Se for o Vim e você ficar preso, digite :q! e enter para sair, ou tente configurar o VS Code como editor padrão).
Se conseguiu sair, faça o commit normalmente com -m.
Git Log:
Use git log no repositório acima.
Tente usar git log --oneline para ver uma versão resumida.

Explicação Extra

Seus arquivos b.txt e c.txt continuaram como "Untracked" (não rastreados) no passo 1. Isso mostra que o Git só commita o que você explicitamente adiciona com git add.

Exercícios da Aula 04

🛠 Exercícios

Manipulação de Branches:
Abra seu terminal no repositório exercicio-03 (ou crie um novo).
Verifique em qual branch você está com git branch (a atual tem um asterisco *).
Crie uma branch chamada time-b (git branch time-b).
Mude para ela (git switch time-b).
Divergência de Histórico:
Na branch time-b, crie um arquivo jogador.txt.
Faça o commit: git add . e git commit -m "Novo jogador".
Mude de volta para a branch principal (main ou master).
Verifique que jogador.txt não existe aqui.
Crie outro arquivo juiz.txt na branch principal e commite.
Merge Simples:
Agora você quer trazer o jogador para a branch principal.
Certifique-se de estar na branch principal.
Execute: git merge time-b.
Use git log para ver como os históricos se uniram.

Dica Importante

O comando git switch -c nome-da-branch cria E muda para a branch ao mesmo tempo. É um atalho muito útil!

Exercícios da Aula 05

🛠 Exercícios

Provocando um Conflito (Sandbox):
Crie uma pasta treino-conflito, inicie o git.
Crie lista.txt com: "Arroz, Feijão". Commite.
Crie branch lista-nova. Mude "Feijão" para "Feijão Preto". Commite.
Volte para main. Mude "Feijão" para "Feijão Carioca". Commite.
Merge lista-nova.
Resultado: CONFLITO!
Resolvendo o Conflito:
Abra lista.txt.
Você verá os marcadores.
Edite para ficar: "Arroz, Feijão Preto e Carioca" (ou escolha um).
Apague os símbolos <<<, ===, >>>.
Salve.
Finalizando:
Rode git status. Ele dirá "both modified".
Rode git add lista.txt.
Rode git commit.
Rode git log para ver o merge registrado.

Dica

Existem ferramentas visuais (no VS Code, GitKraken) que ajudam a resolver conflitos com cliques, mas aprender a fazer "na mão" é essencial para entender o processo.

Exercícios da Aula 06

🛠 Exercícios

Configurando o Perfil:
Vá em "Settings" > "Profile".
Upload de uma foto (avatar).
Preencha o campo "Bio".
Se tiver, coloque o link do seu LinkedIn no campo URL.
Caça ao Tesouro:
Use a barra de busca do GitHub.
Digite "awesome-python" (ou sua linguagem de preferência).
Encontre um repositório que seja uma lista de recursos (normalmente tem "awesome" no nome).
Dê uma Star.
Entendendo Issues:
Vá no repositório microsoft/vscode (ou outro grande).
Clique na aba "Issues".
Leia alguns títulos para entender que tipos de problemas são reportados (Bugs, Feature Requests).
Não comente nada! Apenas observe.

Dica

Manter um perfil ativo e organizado é essencial para quem busca emprego na área. O GitHub é seu portfólio vivo.

Exercícios da Aula 07

🛠 Exercícios

A Prática do Clone:
Saia da pasta do seu projeto (cd ..).
Clone um repositório público qualquer, por exemplo, o guia de markdown: git clone https://github.com/adam-p/markdown-here.git
Entre na pasta criada.
Dê um git log e veja que você tem todo o histórico do projeto de outra pessoa!
O Arquivo .gitignore:
No seu repo de teste (teste-local):
Crie um arquivo chamado segredo.txt.
Crie um arquivo chamado .gitignore.
Dentro do .gitignore escreva: segredo.txt.
Tente dar git add segredo.txt.
O Git vai ignorar/reclamar. Isso prova que funcionou.
Verificando Remotes:
Digite git remote -v.
Você verá os endereços de fetch (onde baixa) e push (para onde envia).

Atenção com Senhas

Nunca suba arquivos com senhas reais para o GitHub Público. Se acontecer, considere a senha comprometida e mude-a imediatamente no serviço original.

Exercícios da Aula 08

🛠 Exercícios

Self-Review:
Abra o PR que você criou no exercício anterior.
Na aba "Files changed", revise seu próprio código.
Encontrou um erro de digitação?
Volte ao terminal (feature-pr), corrija, commite e dê push novamente.
Veja que o PR no GitHub atualiza automaticamente com o novo commit. Mágica!
Fechando sem Merge:
Crie outra branch e outro PR de teste.
Imagine que a ideia foi rejeitada.
Clique em "Close pull request" no final da página (botão cinza).
O código não entra na main. A história da branch fica salva, mas "arquivada".
Explorando Projetos Open Source:
Visite um repo grande (ex: facebook/react).
Vá na aba "Pull Requests".
Veja quantos estão abertos. Entre em um que esteja "Closed" (Fechado/Aceito).
Leia a conversa. Veja como os desenvolvedores discutem soluções. Isso é uma aula de engenharia de software gratuita.

Dica

Em empresas, é comum proteger a branch main para que NINGUÉM consiga dar push direto nela. Tudo DEVE passar por PR e Code Review.

Exercícios da Aula 09

🛠 Exercícios

Investigação de Branches:
Execute git branch -a.
O -a mostra branches locais e remotas (remotes/origin/...).
Veja se você tem branches antigas "mentindo" no seu computador que já foram mergeadas e deletadas no GitHub.
Use git fetch --prune para limpar a lista de branches remotas que não existem mais.
Limpeza Local:
Se você já mergeou a branch feature-pr (da aula passada), delete-a do seu computador para manter a ordem.
Comando: git branch -d feature-pr.
Se o Git reclamar que não foi mergeada (e você sabe que foi, ou não importa), use -D (maiúsculo) para forçar.
Fluxo Rápido:
Tente fazer o ciclo todo (Criar branch, mudar arquivo, commitar, push) em menos de 2 minutos.
O GitHub Flow depende de agilidade. Com a prática, esses comandos viram memória muscular.

Dica

Mantenha seu repositório limpo. Branches velhas só causam confusão. Mergeou? Deletou.

Exercícios da Aula 10

🛠 Exercícios

A Palavra Mágica:
Crie uma Issue de teste: "Corrigir erro de digitação". Anote o número dela (ex: #5).
Vá no seu código, faça uma alteração boba, commite e dê push.
Abra um PR.
Na descrição do PR, escreva: Fixes #5.
Faça o Merge do PR.
Vá na aba Issues e veja que a #5 foi fechada e movida para "Done" (se configurado) sozinha!
Templates de Issue:
Vá em Settings > General > Features > Issues > Set up templates.
O GitHub permite criar formulários padrão para que as pessoas reportem bugs do jeito certo (obrigando a colocar versão do SO, prints, etc).
Tente criar um template simples de "Bug Report".
Milestones:
Crie um Milestone chamado "v1.0 - Lançamento Oficial".
Defina uma data de entrega (Due date) para daqui a 1 mês.
Associe todas as suas issues abertas a esse Milestone.
Acompanhe a barra de progresso verde crescendo conforme você fecha issues.

Dica

Gerentes de Projeto adoram o GitHub Projects. Se você souber usar, ganha pontos extras na entrevista.

Exercícios da Aula 11

🛠 Exercícios

O Detetive de Commits:
Vá no histórico de um projeto Open Source (ex: facebook/react).
Leia os títulos dos commits recentes.
Veja como eles usam tags como [DevTools], Fix, etc.
Tente encontrar um commit ruim (é difícil em projetos grandes, mas acontece).
Reescrevendo a História (Local):
Crie um arquivo provisorio.txt. Commite com mensagem "teste".
Crie um arquivo esquece.txt. Commite com mensagem "outro teste".
Use git rebase -i HEAD~2 (Avançado, cuidado!).
Tente mudar a mensagem "teste" para "chore: adiciona arquivo provisório".
Se achar muito complexo, use apenas o --amend no último commit.
Atomicidade na Prática:
Edite 3 arquivos ao mesmo tempo.
Use git add -p (patch).
O Git vai perguntar pedaço por pedaço (hunk) se você quer adicionar.
Responda y (sim) ou n (não) para separar as mudanças em commits diferentes.

Dica

Commits bem escritos são uma carta de amor para o seu "eu do futuro" (que vai precisar ler isso daqui a 6 meses).

Exercícios da Aula 12

🛠 Exercícios

Emojis:
O Markdown suporta emojis nativamente.
Tente usar :rocket:, :tada:, :computer: no seu README.
Veja a lista em gitmoji.dev ou emoji-cheat-sheet.com.
Tabelas:
Tabelas em Markdown são chatas de fazer na mão, mas úteis.

Tente criar uma:

| Projeto | Status |
| :--- | :---: |
| Portfólio | ✅ Concluído |
| E-commerce | 🚧 Em breve |

Checklists:

Crie uma lista de tarefas interativa no README:

- [x] Aprender Git
- [x] Criar GitHub
- [ ] Conseguir emprego

O GitHub renderiza isso como caixinhas clicáveis!

Dica

Existem geradores de README online (como readme.so) que ajudam a montar a estrutura visualmente. Use e abuse!

Exercícios da Aula 13

🛠 Exercícios

GitHub Flow em Equipe:
Se tiver um colega estudando com você:
Adicione-o ao repo.
Peça para ele criar uma branch, commitar e abrir PR.
Você revisa e aprova.
Depois inverta os papéis.
Simulando Conflito de Equipe:
Crie um arquivo agenda.txt no GitHub com: "Reunião 10h".
Localmente, crie agenda.txt com: "Reunião 11h".
Tente dar git add, commit e push.
Veja a mensagem de erro. Leia a mensagem, ela te diz exatamente o que fazer (git pull ...).
Faça o pull, resolva o conflito, e dê o push.
Revisão de Permissões:
Vá nas configurações do repo.
Tente achar onde se protege a branch main ("Branch protection rules").
Isso exige repositório Pro em contas privadas, ou é grátis em repos públicos.
Tente criar uma regra que exige "Require a pull request before merging".

Dica

Em empresas, a branch main é SEMPRE bloqueada. Ninguém consegue dar push nela, nem o dono. Só via Pull Request aprovado.

Exercícios da Aula 14

🛠 Exercícios

Jekyll Themes (Avançado):
O GitHub Pages suporta geradores de site estático como o Jekyll.
Nas configurações do Pages, procure por "Choose a theme".
Escolha um tema bonito (ex: Minimal).
O GitHub vai criar um arquivo _config.yml e transformar seu README.md em um site bonito automaticamente, sem precisar de index.html.
Teste isso em um repositório novo para não estragar seu portfólio HTML.
Domínio Personalizado:
Se você tiver um domínio .com.br, pode configurar no campo "Custom domain".
O GitHub gera o certificado SSL (HTTPS) de graça.
Deploy Status:
Vá na aba "Actions" do seu repositório.
Veja o workflow "pages-build-deployment".
Se ficar verde, deu tudo certo. Se ficar vermelho, clique para ver o erro (geralmente erro de sintaxe HTML ou nome de arquivo errado).

Dica

Existem templates prontos de portfólio na internet. Busque por "GitHub Pages Portfolio Template", faça um Fork, mude os textos e use como seu!

Exercícios da Aula 15

🛠 Exercícios

Git Reflog (O Salvador):
Digite git reflog.
Você verá uma lista de tudo o que fez, mesmo os commits deletados ou perdidos em resets.
Se você fez um git reset --hard e se arrependeu, pode achar o hash anterior no reflog e voltar para ele.
Pratique: git reset --hard <HASH-ANTERIOR-DO-REFLOG>.
Amend (Correção Rápida):
Commite um arquivo.
Lembre que esqueceu de adicionar outro arquivo nesse mesmo commit.
Dê git add arquivo-esquecido.
Dê git commit --amend --no-edit (o --no-edit mantém a mensagem original).
Agora o commit tem os dois arquivos.
Stash (A Gaveta):
Você está trabalhando na branch feature, arquivo todo bagunçado.
Chefe pede: "Corrige um bug na main AGORA".
Você não quer commitar código quebrado.
Use git stash. O git status fica limpo.
Vá na main, corrija, volte.
Use git stash pop para trazer sua bagunça de volta.

Dica

Aprender reset, reflog e stash te coloca no Top 10% dos usuários de Git. A maioria só sabe add, commit e push.

Exercícios da Aula 16

🛠 Exercícios

A Caça ao Bug (Open Source):
Vá em github.com/explore.
Filtre por tópicos que você gosta (ex: javascript, python).
Tente achar um projeto pequeno.
Leia o CONTRIBUTING.md (se existir). É o manual de como ajudar.
Git Alias (Produtividade):
Cansado de digitar git checkout?
Configure atalhos: git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status
Agora você pode digitar apenas git st!
O Certificado:
Não emitimos certificado oficial, mas seu perfil no GitHub É seu certificado.
Tire um print do seu site no ar e poste no LinkedIn marcando seus aprendizados. "Acabei de construir meu portfólio com Git e GitHub Pages!".

Dica Final

A melhor forma de aprender é ensinando. Escreva um artigo no dev.to ou Medium sobre "O que aprendi com meu primeiro git push".

Quizzes

Quizzes Interativos

Teste seus conhecimentos com quizzes interativos para cada aula!

Módulo 1 – Fundamentos
Módulo 2 – Estruturas de Controle
Módulo 3 – Funções
- Quiz 09 - Funções I
- Quiz 10 - Módulos
Módulo 4 – Arquivos e Exceções
- Quiz 11 - Arquivos
- Quiz 12 - Exceções
Módulo 5 – POO
- Quiz 13 - POO Intro
- Quiz 14 - POO Avançado
Módulo 6 – Ecossistema
- Quiz 15 - APIs
- Quiz 16 - Testes

🎯 Como Usar

Responda todas as perguntas antes de verificar o resultado
Use os quizzes para revisar o conteúdo das aulas
Refaça os quizzes até acertar 100%!

Quiz 01

1. Qual é a principal função de um Sistema de Controle de Versão (VCS)?

A) Gerenciar mudanças em arquivos ao longo do tempo.

B) Proteger o computador contra vírus.

C) Editar imagens e vídeos.

D) Apenas fazer backup na nuvem.

2. Quem é o criador do Git?

A) Bill Gates.

B) Steve Jobs.

C) Linus Torvalds.

D) Mark Zuckerberg.

3. Qual a diferença fundamental entre Git e GitHub?

A) Não há diferença, são a mesma coisa.

B) Git é a ferramenta local de versionamento; GitHub é a plataforma de hospedagem na nuvem.

C) Git é pago e GitHub é gratuito.

D) Git é para Windows e GitHub para Linux.

4. O que significa dizer que o Git é "Distribuído"?

A) Que ele precisa de internet o tempo todo.

B) Que ele divide os arquivos em pedaços pequenos.

C) Que ele é vendido em várias lojas.

D) Que cada usuário tem uma cópia completa do histórico do repositório em sua máquina.

5. Qual problema o Git resolve primariamente?

A) A confusão de múltiplas cópias de arquivos (ex: final_v1, final_v2).

B) A lentidão da internet.

C) A falta de espaço no disco rígido.

D) A dificuldade de programar em Python.

Quiz 02

1. Qual é o site oficial para baixar o Git?

A) github.com

B) git-scm.com

C) git-download.com

D) microsoft.com/git

2. Qual comando define seu nome de usuário no Git?

A) `git config --global user.name "Nome"`

B) `git set user "Nome"`

C) `git name --add "Nome"`

D) `git user.name = "Nome"`

3. O que a opção `--global` faz nas configurações?

A) Envia suas configurações para a internet.

B) Aplica a configuração apenas para a pasta atual.

C) Aplica a configuração para todos os repositórios no seu computador.

D) Formata o computador.

4. Qual terminal é instalado junto com o Git no Windows?

A) PowerShell Pro.

B) Linux Terminal.

C) Command Prompt Plus.

D) Git Bash.

5. Como verificar as configurações atuais do Git?

A) `git show config`

B) `git config --list`

C) `git verify`

D) `git status`

Quiz 03

1. Qual comando cria um novo repositório Git?

A) `git start`

B) `git init`

C) `git create`

D) `git new`

2. O comando `git add` move o arquivo para qual área?

A) Working Directory

B) Repository

C) Staging Area

D) Lixeira

3. Qual a função do `git commit`?

A) Salvar as mudanças da Staging Area permanentemente no histórico.

B) Enviar o código para a internet.

C) Apagar o arquivo.

D) Adicionar o arquivo para ser rastreado.

4. Para que serve o comando `git status`?

A) Ver quem é o dono do projeto.

B) Ver a velocidade da internet.

C) Ver o histórico de mudanças.

D) Ver o estado atual dos arquivos (modificados, preparados, etc).

5. Qual comando exibe a lista de commits realizados?

A) `git history`

B) `git log`

C) `git show`

D) `git list`

Quiz 04

1. Qual é o nome padrão mais comum e recomendado para o branch principal atualmente?

A) trunk

B) root

C) main

D) admin

2. Qual a principal vantagem de usar branches?

A) Deixar o computador mais rápido.

B) Isolar o desenvolvimento de novas funcionalidades sem quebrar o código principal.

C) Criptografar os arquivos.

D) Comprimir o tamanho do projeto.

3. Qual comando cria um novo branch chamado "login"?

A) `git branch login`

B) `git create login`

C) `git start login`

D) `git new login`

4. Qual comando usamos para trocar do branch atual para o branch "main"?

A) `git go main`

B) `git move main`

C) `git change main`

D) `git switch main` (ou `git checkout main`)

5. O comando `git merge feature` faz o que?

A) Apaga o branch feature.

B) Traz as mudanças do branch `feature` para o branch onde você está agora.

C) Envia suas mudanças para a internet.

D) Cria um conflito propositalmente.

Quiz 05

1. Quando ocorre tipicamente um conflito de merge?

A) Quando dois arquivos têm nomes diferentes.

B) Quando a mesma parte do mesmo arquivo foi alterada de formas diferentes em branches diferentes.

C) Quando a internet cai durante o merge.

D) Quando o computador está sem memória.

2. Como o Git resolve conflitos na mesma linha automaticamente?

A) Ele escolhe a alteração mais recente.

B) Ele escolhe a alteração do dono do repositório.

C) Ele mistura as duas linhas aleatoriamente.

D) Ele NÃO resolve automaticamente; ele pausa e pede intervenção humana.

3. O que significam as linhas entre `<<<<<<< HEAD` e `=======`?

A) O conteúdo da branch onde você está atualmente (Target).

B) O conteúdo que está vindo da outra branch (Source).

C) O conteúdo original antes de qualquer mudança.

D) Um erro de codificação do arquivo.

4. Qual comando usamos para dizer ao Git que o conflito foi resolvido?

A) `git resolve`

B) `git status`

C) `git add`

D) `git merge --continue`

5. O que devemos fazer com os marcadores de conflito (`<<<<`, `====`, `>>>>`) ao editar o arquivo?

A) Devemos apagá-los completamente, deixando apenas o código correto.

B) Devemos mantê-los para histórico.

C) Devemos transformá-los em comentários.

D) O Git apaga sozinho depois do commit.

Quiz 06

1. Para que serve o botão "Star" em um repositório GitHub?

A) Para denunciar o projeto.

B) Para adicionar aos favoritos e mostrar apreço.

C) Para baixar o código.

D) Para copiar o projeto para sua conta.

2. O que o "Fork" faz?

A) Cria uma cópia independente do repositório na sua conta.

B) Apaga o repositório original.

C) Junta dois repositórios em um só.

D) Serve para comer espaguete de código.

3. O que são "Issues" no GitHub?

A) Problemas irresolvíveis.

B) Uma revista eletrônica.

C) Um sistema de rastreamento de tarefas, bugs e sugestões.

D) Arquivos de configuração.

4. Onde vejo a frequência de contribuições de um usuário (os quadradinhos verdes)?

A) Na página de configurações.

B) Na página de login.

C) Em nenhum lugar, isso é privado.

D) No perfil do usuário (Contribution Graph / Heatmap).

5. Repositórios definidos como "Private" (Privados):

A) Podem ser vistos por todos, mas só o dono pode editar.

B) Só podem ser vistos pelo dono e colaboradores convidados.

C) Custam dinheiro para serem criados.

D) Não suportam Git.

Quiz 07

1. Qual comando envia os commits do seu computador para o GitHub?

A) `git send`

B) `git upload`

C) `git push`

D) `git commit`

2. O que é "origin" no comando `git remote add origin URL`?

A) É um comando do sistema operacional.

B) É um apelido (alias) padrão para o endereço do repositório remoto.

C) É o nome da branch principal.

D) É o servidor do Google.

3. Qual comando baixa uma cópia completa de um repositório remoto para sua máquina?

A) `git clone`

B) `git download`

C) `git pull`

D) `git fork`

4. Para que serve o arquivo `.gitignore`?

A) Para listar arquivos que o Git deve ignorar e não rastrear.

B) Para limpar a lixeira do computador.

C) Para bloquear usuários indesejados.

D) Para ignorar commits errados.

5. Se eu quiser baixar apenas as atualizações recentes de um repo que já clonei, devo usar `git clone` novamente?

A) Sim, sempre.

B) Não, usar `clone` de novo vai criar uma pasta duplicada ou dar erro. (O correto seria `git pull`).

C) Sim, mas com a opção `--update`.

D) Não, devo apagar a pasta e clonar de novo.

Quiz 08

1. Qual é o pré-requisito técnico para abrir um Pull Request no GitHub?

A) Ter uma conta paga no GitHub.

B) Ter enviado (push) uma branch com alterações para o repositório remoto.

C) Ter o Git instalado em dois computadores.

D) Ter finalizado o projeto inteiro.

2. Na aba "Files changed" de um PR, o que vemos?

A) Os arquivos que foram deletados apenas.

B) O histórico de conversas do time.

C) O "Diff" (diferença) mostrando exatamente o que mudou (linhas verdes adicionadas, vermelhas removidas).

D) As configurações do repositório.

3. O que é Code Review?

A) Um software que revisa código automaticamente.

B) O processo onde outros desenvolvedores leem, testam e comentam sobre seu código antes de aceitá-lo.

C) Uma reunião presencial obrigatória.

D) Um plugin do VS Code.

4. Quem deve fazer o merge de um Pull Request idealmente?

A) O dono da empresa.

B) O próprio autor, sem revisão.

C) O sistema automático à meia-noite.

D) Outra pessoa da equipe, após aprovar as mudanças.

5. Após o PR ser mergeado no GitHub, sua branch local `main` está atualizada?

A) Sim, magicamente.

B) Não, você precisa rodar `git pull origin main` no seu computador para baixar a nova versão.

C) Sim, mas só se o computador estiver ligado.

D) Não, você precisa deletar a pasta e clonar de novo.

Quiz 09

1. Qual é a regra de ouro da branch `main` no GitHub Flow?

A) Ela só é atualizada uma vez por ano.

B) Ela deve estar sempre em estado implantável (deployable), ou seja, funcionando perfeitamente.

C) Ela é onde todos devem commitar diretamente.

D) Ela é deletada a cada mês.

2. Qual a principal diferença entre GitHub Flow e Git Flow?

A) O Git Flow é pago.

B) O GitHub Flow é um fluxo simplificado baseado em branches de feature e main; o Git Flow é mais complexo com várias branches de longo prazo.

C) O GitHub Flow não usa Pull Requests.

D) O Git Flow só funciona no GitLab.

3. No GitHub Flow, o que você deve fazer antes de começar QUALQUER nova tarefa?

A) Pedir permissão ao chefe.

B) Criar uma nova branch descritiva a partir da main.

C) Formatar o computador.

D) Fazer um backup em pen drive.

4. Quando o Deploy (colocar no ar) deve acontecer no GitHub Flow?

A) A cada sexta-feira 18h.

B) Imediatamente após (ou durante) o merge na branch main.

C) Apenas quando o cliente pedir.

D) Quando a lua estiver cheia.

5. O que acontece com a branch de feature (`minha-feature`) após o merge na main?

A) Ela deve ser guardada para sempre como backup.

B) Ela se torna a nova main.

C) Ela pode (e deve) ser deletada, pois seu código já está na main.

D) Ela é enviada para outro repositório.

Quiz 10

1. O campo "Assignee" em uma Issue indica:

A) Quem criou a issue.

B) Quem é o responsável por resolver a tarefa.

C) Quem será demitido se a tarefa falhar.

D) Quem aprovou o orçamento.

2. Labels (etiquetas) servem principalmente para:

A) Deixar o projeto colorido e bonito.

B) Filtrar, categorizar e priorizar issues e PRs.

C) Traduzir o projeto.

D) Aumentar a velocidade do site.

3. Qual palavra-chave na descrição de um PR fecha automaticamente a Issue #42?

A) `Delete #42`

B) `Refers to #42`

C) `Closes #42` (ou `Fixes #42`, `Resolves #42`)

D) `Goodbye #42`

4. O GitHub Projects permite visualizar tarefas em qual formato popular de gestão?

A) Kanban (Colunas: A fazer, Fazendo, Feito).

B) Planilha Excel.

C) Diagrama de Classes.

D) Fluxograma.

5. Issues servem apenas para reportar Bugs?

A) Sim, exclusivamente para erros.

B) Não, servem para sugestões de melhoria (Features), discussões, tarefas e bugs.

C) Não, servem apenas para chat.

D) Sim, e só o dono do repo pode criar.

Quiz 11

1. Qual é a forma recomendada de escrever o verbo no início de uma mensagem de commit (em português)?

A) Passado ("Adicionou botão").

B) Gerúndio ("Adicionando botão").

C) Imperativo ("Adiciona botão").

D) Futuro ("Adicionará botão").

2. O que caracteriza um "Commit Atômico"?

A) Um commit que explode o repositório.

B) Um commit que contém mudanças para resolver apenas uma questão específica (bug ou feature).

C) Um commit com mais de 100 arquivos.

D) Um commit feito por um físico nuclear.

3. No padrão Conventional Commits, qual prefixo indica uma correção de falha?

A) `new:`

B) `upd:`

C) `feat:`

D) `fix:`

4. Por que não devemos commitar correções de bugs e formatação de código juntos?

A) Porque o Git não deixa.

B) Porque fica difícil reverter apenas a formatação ou apenas o bug se algo der errado.

C) Porque ocupa mais espaço em disco.

D) Porque é ilegal.

5. Qual mensagem de commit abaixo é a MELHOR?

A) `outras mudanças`

B) `resolvendo problema do header e mudando cor do botão`

C) `fix: corrige alinhamento do menu mobile`

D) `bug resolvido`

Quiz 12

1. Qual caractere (ou caracteres) define um Título de Nível 1 (H1) em Markdown?

A) `=`

B) `#`

C) `*`

D) `

`

2. Como deixamos um texto em negrito (bold)?

A) `**Texto**` ou `__Texto__`

B) `*Texto*`

C) `~Texto~`

D) `[b]Texto[/b]`

3. Qual a diferença de sintaxe entre um link e uma imagem?

A) Nenhuma.

B) Imagens usam chaves `{}`.

C) A imagem começa com um ponto de exclamação `!`. Ex: `![Alt](url)`.

D) O link começa com `@`.

4. Para criar um bloco de código de várias linhas com destaque de sintaxe, usamos:

A) Aspas triplas `"""`.

B) Parênteses `((()))`.

C) Crases triplas (backticks) ` ``` `.

D) Indentação com 4 espaços apenas.

5. Qual destes NÃO é um serviço de geração de Badges?

A) Shields.io

B) Badgen.net

C) GitHub Badges

D) Badgify (fictício, ou menos conhecido).

Quiz 13

1. Para adicionar um membro da equipe com acesso de escrita ao repositório, onde vamos?

A) No arquivo README.

B) Settings > Collaborators.

C) Insights > Contributors.

D) Profile > Settings.

2. Qual a diferença funcional entre um Colaborador e um Contribuidor externo (Fork)?

A) O Colaborador pode fazer push direto no repositório; o Contribuidor precisa fazer Fork e PR.

B) O Colaborador é pago.

C) O Contribuidor tem mais poderes que o Colaborador.

D) Nenhuma.

3. O que acontece se eu tentar dar `git push` mas houver mudanças no servidor que eu ainda não baixei?

A) O Git apaga as mudanças do servidor.

B) O Git força o envio.

C) O Git rejeita o comando (Rejected - non-fast-forward) e pede um `git pull`.

D) O computador desliga.

4. Qual é a prática recomendada antes de começar a codar todos os dias?

A) `git push -f`

B) `git init`

C) `git pull origin main` (para garantir que estou atualizado).

D) Deletar a pasta `.git`.

5. Quem pode deletar o repositório inteiro?

A) Qualquer pessoa que tenha o link.

B) Apenas o Owner (Dono) e Admins.

C) Os Colaboradores com permissão de leitura.

D) O CEO do GitHub.

Quiz 14

1. O GitHub Pages é ideal para hospedar qual tipo de projeto?

A) Lojas virtuais complexas com banco de dados.

B) Sites estáticos (Portfólios, Landing Pages, Blogs, Documentação).

C) Jogos multiplayer online em tempo real.

D) Sistemas bancários.

2. O que acontece se eu não tiver um arquivo `index.html` (e não usar Jekyll)?

A) O site explode.

B) O GitHub cobra uma taxa.

C) O navegador mostra o conteúdo do README.md (se configurado) ou um erro 404 (Página não encontrada).

D) O GitHub cria um index automaticamente com suas fotos.

3. Qual arquivo precisamos editar para configurar temas do Jekyll?

A) `package.json`

B) `index.php`

C) `_config.yml`

D) `.htaccess`

4. Quanto custa hospedar um site no GitHub Pages para um repositório público?

A) $7/mês.

B) É gratuito.

C) $0.01 por acesso.

D) Gratuito apenas por 30 dias.

5. Qual é o domínio padrão gerado pelo GitHub Pages?

A) `projeto.com`

B) `github.com/site/usuario`

C) `usuario.github.io/projeto`

D) `pages.github.com`

Quiz 15

1. O que o comando `git restore arquivo.txt` faz (em versões modernas do Git)?

A) Restaura o arquivo do último backup do Windows.

B) Descarta as mudanças feitas no arquivo no Working Directory, revertendo para o estado do último commit.

C) Apaga o arquivo para sempre.

D) Envia o arquivo para a lixeira.

2. Qual a diferença entre `git reset --soft` e `git reset --hard`?

A) O Soft apaga tudo; o Hard mantém.

B) O Soft mantém suas mudanças na área de Stage; o Hard apaga todas as mudanças e reverte os arquivos.

C) Não há diferença.

D) O Hard é mais rápido.

3. Para que serve o `git stash`?

A) Para guardar mudanças temporariamente ("na gaveta") sem commitar, permitindo trocar de branch com segurança.

B) Para deletar branches.

C) Para ver o histórico.

D) Para criar tags.

4. Se eu fiz um commit numa branch, mudei para outra e perdi o commit (Detached HEAD), onde posso encontrar o hash dele para recuperar?

A) No `git status`.

B) No `git log` da main.

C) No `git reflog`.

D) Google.

5. O que fazer se o Git disser `error: Your local changes to the following files would be overwritten by checkout`?

A) Chorar.

B) Commitar suas mudanças ou usar `git stash` antes de trocar de branch.

C) Forçar a troca e perder tudo.

D) Desinstalar o Git.

Quiz 16

1. O que é o "Heatmap" (Gráfico de Contribuição) no perfil do GitHub?

A) Um gráfico que mostra a temperatura do servidor.

B) Um calendário visual que mostra a frequência das suas contribuições (commits, PRs, issues) ao longo do ano.

C) Um jogo de batalha naval.

D) Um contador de seguidores.

2. Qual evento anual incentiva a participação em projetos Open Source?

A) GitCon.

B) CodeFest.

C) Hacktoberfest.

D) Summer of Code.

3. O que significa CI/CD?

A) Código Interno / Código Dedicado.

B) Continouos Integration / Continuous Delivery (ou Deployment).

C) Command Interface / Command Delete.

D) Central Intelligence / Central Data.

4. O que são Git Hooks?

A) Ganchos de metal para pendurar o computador.

B) Scripts que o Git executa automaticamente antes ou depois de eventos como commit, push e merge.

C) Erros de versionamento.

D) Vírus.

5. Qual é o melhor conselho para quem está começando na carreira de dev?

A) Decorar todos os comandos do Git.

B) Nunca pedir ajuda.

C) Praticar consistentemente, construir projetos reais e colaborar com outros (Soft Skills).

D) Usar apenas bloco de notas.

Projetos

Projetos Práticos

Desenvolva projetos práticos para aplicar o que você aprendeu!

Módulo 1 – Fundamentos
Módulo 2 – Estruturas de Controle
Módulo 3 – Funções
- Projeto 09 - Conversor de Temperaturas
- Projeto 10 - Jogo da Forca
Módulo 4 – Arquivos e Exceções
- Projeto 11 - To-Do List Persistente
- Projeto 12 - Calculadora Robusta
Módulo 5 – POO
- Projeto 13 - Biblioteca
- Projeto 14 - RPG Simples
Módulo 6 – Ecossistema
- Projeto 15 - Buscador GitHub
- Projeto 16 - Task Manager (TDD)

🚀 Dicas para os Projetos

Leia o enunciado com atenção - Entenda o que é pedido
Planeje antes de codificar - Pense na estrutura
Teste incrementalmente - Não espere terminar tudo para testar
Refatore seu código - Melhore a qualidade após funcionar
Compartilhe seus projetos - Mostre o que você criou!

Projeto da Aula 01

🚀 Projeto da Aula: Repositório de Portfólio no GitHub

Neste curso, vamos desenvolver um Portfólio Profissional que servirá como seu cartão de visitas no mundo da tecnologia.

Passo 1: Preparação do Ambiente

Vá até a pasta Documentos do seu computador.
Crie uma nova pasta chamada meu-portfolio-git.
Nota: Evite usar espaços em nomes de pastas de projetos (use hífens ou underlines).

Passo 2: O Primeiro Arquivo

Abra essa pasta.
Usando o Bloco de Notas ou VS Code, crie um arquivo chamado sobre.txt.
Dentro dele, escreva apenas seu nome completo e uma breve descrição (ex: "Estudante de Análise e Desenvolvimento de Sistemas").
Salve o arquivo.

O que fizemos?

Por enquanto, apenas criamos a estrutura. Nas próximas aulas, vamos transformar essa pasta comum em um Repositório Git e conectá-la ao GitHub. Mantenha essa pasta salva!

Projeto da Aula 02

🚀 Projeto da Aula: Preparando o Ambiente

Nesta etapa, vamos garantir que sua "bancada de trabalho" está pronta.

Passo 1: O Terminal Correto

Volte à pasta meu-portfolio-git que você criou na Aula 01.
Se você usa Windows:
Clique com o botão direito em um espaço vazio dentro da pasta.
Escolha a opção "Open Git Bash Here".
Uma janela preta (ou colorida) vai abrir. Note que o caminho da pasta já aparece nela (ex: /c/Users/voce/Documents/meu-portfolio-git).
Se você usa Mac/Linux:
Abra o Terminal.
Digite cd ~/Documents/meu-portfolio-git (ajuste o caminho se necessário) para entrar na pasta.

Passo 2: Teste Final

No terminal aberto dentro da pasta, digite:

git status

Você deve ver uma mensagem de erro dizendo fatal: not a git repository. ISSO É BOM! Significa que o Git está instalado, funcionando, mas (corretamente) avisou que aquela pasta ainda não é um repositório. Faremos isso na Aula 03.

Projeto da Aula 03

🚀 Projeto da Aula: Primeiro Commit no Portfólio

Agora vamos oficializar nosso projeto.

Passo 1: Inicializar

No terminal, dentro da pasta meu-portfolio-git.
Execute:
```
git init
```
Terminal deve responder: Initialized empty Git repository in...

Passo 2: Verificar Estado

Execute:
```
git status
```
Terminal: Mostrará sobre.txt em vermelho (Untracked files).

Passo 3: Preparar (Staging)

Execute:
```
git add sobre.txt
```
Execute git status novamente. Terminal: Mostrará sobre.txt em verde (Changes to be committed).

Passo 4: Commitar (Salvar)

Execute:
```
git commit -m "Cria arquivo inicial sobre mim"
```
Terminal: [master (root-commit)...] 1 file changed...

Passo 5: Conferir

Execute:
```
git log
```
Você verá seu nome, email, data e a mensagem do commit. Parabéns, seu projeto está versionado!

Projeto da Aula 04

🚀 Projeto da Aula: Trabalhando com Branches

Vamos simular um fluxo real de trabalho no nosso portfólio.

Passo 1: Nova Funcionalidade

Você quer adicionar seu email, mas não tem certeza se vai ficar bom. Vamos fazer em uma branch segura. 1. No terminal do meu-portfolio-git:

git branch contato
git switch contato

(Ou use apenas git switch -c contato).

Passo 2: A Alteração

Crie um novo arquivo chamado contato.txt.
Escreva seu email dentro dele.
Salve.

Adicione e commite:

git add contato.txt
git commit -m "Adiciona email de contato"

Passo 3: A Validação

Troque de volta para a branch principal (pode se chamar master ou main, verifique com git branch para saber qual é a correta):
```
git switch master
```
(Use main se for o caso).
Olhe a pasta. O arquivo contato.txt sumiu. Isso prova que o trabalho estava isolado.

Passo 4: O Merge

Você decidiu que a funcionalidade está boa e quer incorporá-la. 1. Estando na branch principal, digite:

git merge contato

2. O arquivo contato.txt reaparece magicamente. Agora ele faz parte da versão oficial do seu projeto!

Projeto da Aula 05

🚀 Projeto da Aula: Conflito no Portfólio

Vamos criar um conflito controlado para perder o medo.

Passo 1: O Cenário

No seu meu-portfolio-git, certifique-se de estar na main e sem pendências (git status limpo).
Crie uma branch melhoria-texto: git switch -c melhoria-texto.
Abra o sobre.txt. Mude a linha do seu nome para: "Nome: [Seu Nome] - Desenvolvedor Full Stack".
Salve e commite: git commit -am "Melhora descrição na branch".

Passo 2: A Divergência

Volte para a main: git switch main.
Abra o sobre.txt. Note que a mudança acima não está lá.
Mude a linha do seu nome para: "Nome: [Seu Nome] - Especialista em Git".
Salve e commite: git commit -am "Muda descrição na main".

Passo 3: O Conflito

Tente unir as branches: git merge melhoria-texto.
BOOM! Merge conflict in sobre.txt.

Passo 4: A Resolução

Abra sobre.txt. Veja a confusão.
Decida como você quer se apresentar. Talvez unir os dois? "Nome: [Seu Nome] - Desenvolvedor Full Stack e Especialista em Git".
Apague as linhas de controle (<<<, ===, >>>).
Salve.
No terminal: git add sobre.txt.
git commit. (Pode deixar a mensagem padrão).
Pronto! Histórico unificado e paz restaurada.

Projeto da Aula 06

🚀 Projeto da Aula: Explorando o Terreno

Nesta aula focada na interface do GitHub, seu projeto é o seu próprio PERFIL.

Passo 1: A Vitrine

Vá até seu perfil (github.com/seu-usuario).
Se estiver vazio ("You don't have any public repositories yet"), não se preocupe. Vamos mudar isso na próxima aula.
Observe o botão "Edit Profile".

Passo 2: Profissionalização

Nome: Use seu nome real, não um apelido de jogo (ex: "DarkSlayer99"). Recrutadores vão ver isso!
Bio: Uma frase curta. Ex: "Estudante de ADS | Apaixonado por Java e Cloud".
Localização: Ajuda em vagas presenciais/híbridas.

Passo 3: Segurança

Vá em Settings > Password and authentication.
Recomendamos ativar Two-factor authentication (2FA).
Isso impede que alguém roube sua conta e apague seus projetos.
Você pode usar um app como Google Authenticator ou Authy.

Pronto! Sua "identidade digital" está configurada. Na Aula 07, vamos conectar seu computador a ela.

Projeto da Aula 07

🚀 Projeto da Aula: Conectando com o Mundo

Seu projeto agora vive na nuvem.

Passo 1: Conferência

Acesse o GitHub e entre no repositório portfolio-dev que você criou.
Navegue pelos arquivos. Você consegue ler o conteúdo do sobre.txt direto no navegador?
Veja o histórico de commits clicando em "Commits" (ícone de reloginho).
Veja que suas mensagens de commit ("Adiciona arquivo sobre mim", "Cria arquivo de contato") estão todas lá, com as datas originais de quando você as fez no seu computador.

O que isso significa?

Significa que seu trabalho local está salvo. Se seu computador pegar fogo hoje, seu código está seguro no GitHub. Isso é o poder do backup distribuído.

Nas próximas aulas, vamos aprender como colaborar com outras pessoas nesse projeto.

Projeto da Aula 08

🚀 Projeto da Aula: O Ciclo Completo

Hoje você vai agir como Gerente e Desenvolvedor ao mesmo tempo.

Passo 1: O Desenvolvedor

No terminal: git switch -c funcionalidade-nova.
Crie um arquivo futuro.txt com suas metas para o ano que vem.
git add . e git commit -m "Minhas metas".
git push -u origin funcionalidade-nova.

Passo 2: O Gerente (GitHub)

Vá ao GitHub. Abra o PR.
Na descrição, escreva: "Adiciona metas ambiciosas para 2026".
Crie o PR.
Finja ser um colega chato: Vá em "Files changed" e comente na linha 1: "Tem certeza dessa meta?".
Volte para "Conversation" e aprove o PR (se o GitHub deixar aprovar o próprio PR, senão apenas faça o Merge).
Clique em Merge pull request.
Clique em Delete branch (limpeza é bom).

Passo 3: Sincronia

Volte ao terminal.
Mude para a main: git switch main.
Tente ver o arquivo: cat futuro.txt (ou dir no windows). Ele não deve existir ainda!
Baixe a atualização:
```
git pull
```
Agora sim, o arquivo apareceu.

Conceito chave: O GitHub virou a "Verdade Absoluta" do projeto. Seu computador apenas envia e recebe atualizações dele.

Projeto da Aula 09

🚀 Projeto da Aula: Implementando o Fluxo Moderno

Vamos simular um dia de trabalho real.

Passo 1: Atualizar

Sempre comece o dia garantindo que seu local está igual ao remoto.

git switch main
git pull

Passo 2: A Tarefa (Feature)

Você precisa adicionar uma lista de "Soft Skills" ao portfólio.

git switch -c feature-soft-skills

Passo 3: O Trabalho

Edite sobre.txt. Adicione: "Soft Skills: Comunicação, Trabalho em Equipe, Resiliência."

git add .
git commit -m "Adiciona lista de soft skills"

Passo 4: O Envio

git push -u origin feature-soft-skills

Passo 5: O PR e Merge

Vá ao GitHub, abra o PR, revise e faça o Merge. Delete a branch remota.

Passo 6: O Ciclo se Fecha

Volte ao terminal.

git switch main
git pull
git branch -d feature-soft-skills

Agora sua main local tem as Soft Skills, e a branch temporária se foi. Limpo e eficiente.

Projeto da Aula 10

🚀 Projeto da Aula: Organização Profissional

Vamos tratar o portfolio-dev como um produto real.

Passo 1: O Backlog

Volte no seu GitHub Project e crie cards para tudo que você imagina que falta no seu portfólio, mesmo que não saiba fazer ainda: - "Colocar ícones de redes sociais". - "Criar versão escura (Dark Mode)". - "Adicionar depoimentos". - "Otimizar para celular".

Passo 2: Priorização

Arraste os cards. O que é mais importante fica no topo da coluna "Todo". O que é "sonho distante" fica no fim.

Passo 3: Execução

Escolha a tarefa mais fácil (ex: adicionar redes sociais no texto).
Mova para "In Progress".
Abra a Issue associada.
Vá no terminal, crie a branch, resolva, envie o PR (como na aula passada).
No PR, use Closes #NUMERO_DA_ISSUE.
Ao mergear, veja a mágica:
A Issue fecha.
O card no Projeto move para "Done" (se a automação estiver ligada) ou você move manualmente, sentindo o prazer da tarefa cumprida.

Projeto da Aula 11

🚀 Projeto da Aula: Limpeza e Qualidade

No quadro do seu projeto no GitHub, pegue a tarefa "Melhorar CSS" (ou similar).

Passo 1: Branch

git switch -c style-improvements

Passo 2: Mudança 1

Se você tiver um arquivo CSS/Estilo no portfólio, mude a fonte para "Verdana" (ou outra). git add . git commit -m "style: altera fonte principal para Verdana"

Passo 3: Mudança 2

Adicione uma cor de fundo. git add . git commit -m "style: define cor de fundo cinza claro"

Passo 4: Push e PR

Envie. No GitHub, veja como é fácil entender o que foi feito em cada passo. Se o revisor gostar da cor mas odiar a fonte, ele pode pedir para reverter apenas o commit da fonte. Se fosse tudo junto, seria um problema.

Hoje não temos exercício de código complexo, o foco é a qualidade da mensagem.

Projeto da Aula 12

🚀 Projeto da Aula: O README Definitivo

No seu portfolio-dev no GitHub:

Header com Imagem: Se tiver um banner ou imagem legal, coloque no topo com ![Banner](url).
Badges: Vá em Shields.io e gere uma badge Status: Estudando. Copie o Markdown e cole logo abaixo do título.
Índice: Se o README for longo, crie um índice clicável (links internos funcionam assim: [Ir para Contato](#-contato) onde -contato é o link gerado pelo título "📫 Contato").
GIF: Se tiver um projeto rodando, grave a tela e coloque um GIF. Nada vende mais que movimento.

Seu repositório agora parece profissional. Compare com aquele sobre.txt da primeira aula. Evolução!

Projeto da Aula 13

🚀 Projeto da Aula: Protegendo o Forte

Já que estamos simulando um ambiente profissional, vamos blindar nosso projeto.

Passo 1: Regras de Branch (Projetos Públicos)

Se seu repositório portfolio-dev for público (gratuito), você pode criar regras de proteção. 1. Vá em Settings > Branches. 2. Clique em Add branch protection rule. 3. Em "Branch name pattern", digite main. 4. Marque "Require a pull request before merging". 5. Marque "Do not allow bypassing the above settings". 6. Clique em Create.

Passo 2: O Teste

Tente alterar algo no seu README localmente.
Tente dar git push origin main.
Se funcionou, você verá um erro dizendo que é proibido dar push na branch protegida!
Vitória! Agora você é obrigado a criar uma branch e abrir um PR, como num time de elite.

(Nota: Se seu repo for privado e conta free, o GitHub pode bloquear essa feature. Nesse caso, apenas entenda o conceito).

Projeto da Aula 14

🚀 Projeto da Aula: Publicando

Seu site já deve estar no ar. Vamos melhorá-lo.

Passo 1: Melhorando o HTML

Adicione uma foto sua. 1. Salve uma foto perfil.jpg na pasta do projeto. 2. Adicione <img src="perfil.jpg" width="150" style="border-radius: 50%;"> antes do <h1> no index.html. 3. git add ., git commit -m "feat: adiciona foto", git push.

Passo 2: O Badge de Deploy

Vá na aba "Actions".
Clique no último workflow de "pages-build-deployment" que deu sucesso.
Procure por "Create status badge" (...) ou vá no README e adicione manualmente.
Adicione isso ao seu README: ![GitHub Pages](https://github.com/SEU-USUARIO/portfolio-dev/actions/workflows/pages/pages-build-deployment/badge.svg) (Ajuste o link conforme necessário, ou pegue a sintaxe correta na aba Actions > Três pontinhos > Create status badge).

Agora quem visitar seu repo saberá que o site está "Passing" (No ar).

Projeto da Aula 15

🚀 Projeto da Aula: O Salvamento

Hoje você vai ser o herói de si mesmo.

Passo 1: O "Desastre"

No portfolio-dev, edite o index.html. Apague todo o conteúdo e escreva "OOPS DELETEI TUDO".
Salve.
Não commite!

Passo 2: O Arrependimento

Olhe para o arquivo e perceba o erro.
Use git restore index.html (ou git checkout -- index.html versão antiga).
Abra o arquivo. A mágica aconteceu? O código original voltou?

Passo 3: O "Desastre" Maior (Reset)

Crie um arquivo lixo.txt.
git add . e git commit -m "Commit inútil".
Olhe o git log. O commit inútil está lá.
Execute git reset --hard HEAD~1 (Cuidado!).
Olhe o git log. O commit sumiu.
Olhe a pasta. O arquivo lixo.txt sumiu. (Nota: --hard é destrutivo para arquivos novos não trackeados ou mudanças. Use com sabedoria).

Parabéns! Você aprendeu a controlar o tempo.

Projeto da Aula 16

🚀 Projeto da Aula: O Legado

Seu projeto meu-portfolio-git (agora portfolio-dev no GitHub) está vivo.

O Grand Finale

Certifique-se de que tudo está mergeado na main.
Certifique-se de que o site está no ar.
Certifique-se de que o README está convidativo.
Adicione um arquivo LICENSE (pode ser MIT License). Isso diz ao mundo que eles podem usar seu código (ou não).
No GitHub: Add file > Create new file > Digite LICENSE > Choose a license template > MIT License.

Você completou o ciclo. De uma pasta vazia a um projeto open source licenciado e hospedado.

Fim do Curso.

Configuração

Configuração do Ambiente

Bem-vindo à seção de configuração! Aqui você encontra guias para instalar e configurar seu ambiente de desenvolvimento Python.

Windows
- Instalação Windows
- Guia completo para Windows 10/11
- Python via Microsoft Store
- VSCode e extensões
Linux (Ubuntu)
- Instalação Linux
- Guia para Ubuntu/Debian
- PyCharm Community
- Configuração do ambiente

📋 Próximos Passos

Após configurar seu ambiente:

✅ Teste a instalação - Execute seu primeiro programa
📚 Comece as aulas - Vá para Aula 01
💪 Pratique - Faça os exercícios propostos
🚀 Desenvolva - Crie seus próprios projetos

Configuração do Ambiente (Windows)

Este guia irá ajudá-lo a configurar o ambiente de desenvolvimento Python no Windows usando o Visual Studio Code (VSCode).

1. Instalando o Python

O Python é a linguagem que usaremos. O interpretador é o programa que lê seu código e diz ao computador o que fazer.

Passo 1: Baixar

Acesse o site oficial: python.org/downloads.
Clique no botão amarelo Download Python 3.x.x (a versão mais recente).

Passo 2: Instalar (MUITO IMPORTANTE!)

Execute o instalador baixado (python-3.x.x-amd64.exe).
⚠️ ANTES DE CLICAR EM INSTALL, MARQUE A CAIXA: [x] Add Python 3.x to PATH (Se você esquecer isso, o Python não vai funcionar no terminal).
Clique em Install Now.
Aguarde o final e clique em Close.

Passo 3: Testar

Abra o Menu Iniciar e digite cmd ou PowerShell. Abra-o.
Digite o comando:
```
python --version
```
Se aparecer algo como Python 3.12.0, parabéns! Está instalado.

2. Instalando o Visual Studio Code (VSCode)

O VSCode é o editor de texto onde escreveremos nosso código. Ele é leve, poderoso e gratuito.

Acesse: code.visualstudio.com.
Baixe a versão para Windows.
Instale com as opções padrão (Next, Next, Install).

3. Configurando o VSCode para Python

Para o VSCode entender Python e ajudar com cores e autocompletar, precisamos de uma extensão.

Abra o VSCode.
No menu lateral esquerdo, clique no ícone de quadrados (Extensions) ou aperte Ctrl+Shift+X.
Na barra de busca, digite Python.
Clique na primeira opção (criada pela Microsoft) e clique em Install.
Aguarde a instalação finalizar (pode pedir para recarregar).

4. Seu primeiro teste no VSCode

Crie uma pasta no seu computador para o curso (ex: MeusEstudosPython).
No VSCode, vá em File > Open Folder e abra essa pasta.
Crie um arquivo novo chamado teste.py.

Escreva:

print("Configuração concluída com sucesso!")

Para rodar, clique no botão de Play ▷ no canto superior direito (ou aperte F5).
A mensagem deve aparecer no terminal na parte de baixo da tela.

🎉 Pronto! Seu ambiente está configurado.

Configuração do Ambiente (Linux Ubuntu)

Este guia mostra como instalar e configurar o Python e PyCharm no Ubuntu para desenvolvimento.

1. Instalando Python no Ubuntu

O Ubuntu já vem com Python instalado. Vamos verificar e atualizar se necessário.

Verificar Versão Instalada

python3 --version

Se aparecer Python 3.10 ou superior, você já tem Python! Caso contrário, instale:

Instalar Python e Ferramentas

# Atualizar repositórios
sudo apt update

# Instalar Python 3 e ferramentas essenciais
sudo apt install python3 python3-pip python3-venv -y

# Verificar instalação
python3 --version
pip3 --version

Saída esperada:

Python 3.12.x
pip 24.x.x

2. Instalando e Configurando PyCharm no Ubuntu

PyCharm é a melhor IDE para Python, desenvolvida pela JetBrains.

Método Recomendado: Via Snap

O Snap já vem instalado no Ubuntu. Use este método para instalação fácil:

# PyCharm Community (Gratuito e Open Source)
sudo snap install pycharm-community --classic

# OU PyCharm Professional (Pago, mas com 30 dias de trial)
sudo snap install pycharm-professional --classic

Método Alternativo: Via Ubuntu Software

Abra Ubuntu Software (ícone de sacola de compras)
Busque por "PyCharm"
Clique em Install

Abrir PyCharm

# Via terminal
pycharm-community

# OU via menu de aplicativos
# Pressione Super (tecla Windows) e digite "PyCharm"

3. Configuração Inicial do PyCharm

Primeira Execução

Aceite os Termos de Uso
Escolha o Tema:
Light (Claro)
Darcula (Escuro) - Recomendado
Criar Novo Projeto:
Clique em New Project
Escolha o local: ~/PycharmProjects/MeuPrimeiroProjeto
Interpreter: Selecione Python 3.x detectado automaticamente
Clique em Create

Configurar Interpretador Python

Se o PyCharm não detectar automaticamente:

File → Settings (ou Ctrl+Alt+S)
Project → Python Interpreter
Clique no ícone de engrenagem → Add
Selecione System Interpreter
Escolha /usr/bin/python3

4. Criando Seu Primeiro Programa

Criar arquivo: Clique com botão direito no projeto → New → Python File
Nome: hello.py
Digite:

print("Olá, Linux!")
print("Python está funcionando!")

Executar: Clique com botão direito no arquivo → Run 'hello'
Ou use o atalho: Shift+F10

5. Instalando Bibliotecas (pip)

Via Terminal do PyCharm

View → Tool Windows → Terminal (ou Alt+F12)
Instalar biblioteca:

pip3 install requests

Criar Ambiente Virtual (Recomendado)

# Criar ambiente virtual
python3 -m venv venv

# Ativar
source venv/bin/activate

# Instalar bibliotecas
pip install requests flask pandas

# Desativar quando terminar
deactivate

6. Atalhos Úteis do PyCharm (Linux)

Atalho	Ação
`Ctrl+Space`	Auto-completar código
`Shift+F10`	Executar programa
`Ctrl+/`	Comentar/descomentar linha
`Ctrl+D`	Duplicar linha
`Ctrl+Y`	Deletar linha
`Ctrl+Alt+L`	Formatar código
`Alt+F12`	Abrir terminal

7. Dicas Importantes

Permissões de Execução

Se encontrar erro de permissão ao executar scripts:

chmod +x seu_script.py

Atualizar pip

pip3 install --upgrade pip

Verificar Pacotes Instalados

pip3 list

8. Solução de Problemas Comuns

Erro: "python: command not found"

Use python3 em vez de python:

python3 seu_script.py

PyCharm não abre

# Via Snap
snap run pycharm-community

# Via Flatpak
flatpak run com.jetbrains.PyCharm-Community

Conflito de versões Python

# Verificar todas as versões instaladas
ls /usr/bin/python*

# Usar versão específica
python3.10 --version

9. Recursos Adicionais

Documentação Python: https://docs.python.org/pt-br/3/
PyCharm Docs: https://www.jetbrains.com/help/pycharm/
Python Package Index (PyPI): https://pypi.org/

✅ Pronto!

Agora você tem um ambiente Python completo no Linux! 🐧🐍

Próximos passos: - Explore os tutoriais integrados do PyCharm - Pratique com exercícios Python - Comece a desenvolver seus projetos!

Versão para Impressão

Esta página foi gerada automaticamente para impressão.